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

[Laszlo Ersek]

On 10/09/15 05:04, Ni, Ruiyu wrote:
> On 2015-10-08 4:59, Bruce Cran wrote:
>> I have a controller which implements the Driver Health Protocol. Under
>> OVMF (built from latest edk2 master), when the controller isn't healthy
>> I can go into the 'Device Manager' menu, click the 'Some drivers are not
>> healthy' entry and on clicking the unhealthy controller it gets repaired.
>>
>> I'm wondering if anyone knows if this is recent behavior or if a bug was
>> fixed, since on my Intel DQ77MK system I have a similar menu, except
>> labeled "TPV EFI Device Manager" - but when I click the "Some drivers
>> are not healthy" item the screen just refreshes back to the same page
>> and nothing happens.
>>
> The OVMF behavior exists for a quite long time, like several years. I
> don't know why the DQ77MK system behaves like that.
>> I had also expected that if I selected a boot item that resides on the
>> unhealthy controller, the repair operation would get invoked and upon it
>> returning a healthy status the OS would boot. But that doesn't seem to
>> be the case.
>>
> OVMF used the old IntelFrameworkModulePkg/BDS.
> The new MdeModulePkg/BDS automatically invokes the reparation upon boot.
> I did a draft patch
> (http://article.gmane.org/gmane.comp.bios.edk2.devel/759) but do not
> have time to edit it to follow the review comments.
> I may not have time to do it in this year. If it's urgent to you, you
> can try this draft patch. It will be great if you can help to edit the
> patch and get it reviewed and checked in to the OVMF Pkg.

Thanks for the info, Ray. Perhaps I'll find the time to pick up that
patch myself. Regarding the individual (numbered) comments that I made
there: I can clearly fix them up. But, the main problem I had with that
patch is that there was a sequence of hunks that were completely
impenetrable to me. I'm unsure if I could "untangle" those.

Anyway, as I said above, thanks for the info -- it's great to know that
you haven't abandoned that patch series, just have more pressing
developments to deal with.

Cheers!
Laszlo


>> Can anyone tell me what I'm misunderstanding please?
>>
> 
> ___
> 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 2/2] MdePkg/PeCoffLoader: fix handling of ARM MOVW/MOVT instruction relocs

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Friday, October 09, 2015 3:24 AM
To: Leif Lindholm
Cc: edk2-devel@lists.01.org; Gao, Liming; Zhu, Yonghong; Kinney, Michael D
Subject: Re: [PATCH 2/2] MdePkg/PeCoffLoader: fix handling of ARM MOVW/MOVT 
instruction relocs

On 6 October 2015 at 13:02, Leif Lindholm  wrote:
> On Tue, Sep 29, 2015 at 10:29:00AM +0200, Ard Biesheuvel wrote:
>> Advance the *FixupData pointer after use in the second relocation 
>> pass for runtime when handling ARM MOVW/MOVT immediate relocations.
>>
>> Note that using FixupData is somewhat pointless for relocations 
>> targeting instructions rather than data items, since the program 
>> cannot typically modify its own instructions, and the second pass 
>> should be performed unconditionally. But let's just fix it for now.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 

@Liming: are you ok with these patches?

>> ---
>>  MdePkg/Library/BasePeCoffLib/Arm/PeCoffLoaderEx.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/MdePkg/Library/BasePeCoffLib/Arm/PeCoffLoaderEx.c 
>> b/MdePkg/Library/BasePeCoffLib/Arm/PeCoffLoaderEx.c
>> index d6bf42738d2b..38f891e2fdaa 100644
>> --- a/MdePkg/Library/BasePeCoffLib/Arm/PeCoffLoaderEx.c
>> +++ b/MdePkg/Library/BasePeCoffLib/Arm/PeCoffLoaderEx.c
>> @@ -234,6 +234,7 @@ PeHotRelocateImageEx (
>>FixupVal = ThumbMovwMovtImmediateAddress (Fixup16) + (UINT32)Adjust;
>>ThumbMovwMovtImmediatePatch (Fixup16, FixupVal);
>>  }
>> +*FixupData = *FixupData + sizeof(UINT64);
>>  break;
>>
>>case EFI_IMAGE_REL_BASED_ARM_MOV32A:
>> --
>> 1.9.1
>
> Reviewed-by: Leif Lindholm 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

[Laszlo Ersek]

On 10/09/15 12:10, HATAYAMA Daisuke wrote:
> Sorry for delayed response.
> 
> From: Laszlo Ersek 
> Subject: Re: [grub PATCH] efinet: disable MNP background polling
> Date: Thu, 1 Oct 2015 13:50:31 +0200
> 

[snip]

>> Here's an example. Boot OVMF, with a virtio-net-pci device enabled in
>> QEMU, and make sure that the NICs ROM BAR does not contain the iPXE
>> driver (-device virtio-net-pci,rombar=0). This will allow OVMF's builtin
>> VirtioNetDxe to bind the device (which I want to use now for
>> illustrating the question). Then, enter the UEFI shell, and issue the
>> following command:
>>
>>> Shell> dh -d -v -p SimpleNetwork
>>> A0: UnknownDevice
>>> LoadFile
>>> PXEBaseCode
>>> TCPv4ServiceBinding
>>> MTFTPv4ServiceBinding
>>> DHCPv4ServiceBinding
>>> UDPv4ServiceBinding
>>> IPv4Config2
>>> IPv4ServiceBinding
>>> ARPServiceBinding
>>> UnknownDevice
>>> ManagedNetworkServiceBinding
>>> VlanConfig
>>> DevicePath PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)
>>> SimpleNetwork
>>>
>>>Controller Name: Virtio Network Device
>>>Device Path: PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)
>>>Controller Type: BUS
>>>Configuration  : NO
>>>Diagnostics: NO
>>>Managed by :
>>>  Drv[6F]  : MNP Network Service Driver
>>>  Drv[70]  : VLAN Configuration Driver
>>>  Drv[73]  : IP4 Network Service Driver
>>>Parent Controllers :
>>>  Parent[8C]   : Virtio Network Device
>>>Child Controllers  :
>>>  Child[A2]: MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x806, 
>>> VlanId=0)
>>>  Child[A3]: MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x800, 
>>> VlanId=0)
>>>  Child[A1]: 
>>> PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)/VenHw(D79DF6B0-EF44-43BD-9797-43E93BCF5FA8)
>>>  Child[A4]: 
>>> PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)/VenHw(9FB1A1F3-3B71-4324-B39A-745CBB015FFF)
>>
>> There is only one handle with an SNP instance on it in the system
>> (because I configured only one virtio-net NIC for the VM). The
>> underlying hardware controller handle (marked as A0 above) has a bunch
>> of other protocol interfaces installed on it. Note the many
>> ___ServiceBinding protocols!
>>
>> (
>> For example, the UEFI spec says about UDPv4ServiceBinding:
>>
>> The EFI UDPv4 Service Binding Protocol is used to locate
>> communication devices that are supported by an EFI UDPv4 Protocol
>> driver and to create and destroy instances of the EFI UDPv4 Protocol
>> child protocol driver that can use the underlying communications
>> device.
>>
>> Multiple consumers could call UDPv4ServiceBinding.CreateChild(), and
>> then use their private UDPv4 protocol interfaces to transmit and receive
>> in parallel.
>> )
>>
>> Also, note that there is *no* MNP instance directly installed on the
>> handle.
>>
>> Anyway, among other things, this handle is open by "MNP Network Service
>> Driver" (which directly provides MNPSB), marked as [6F]. And,
>> apparently, there have been two requests to MNPSB for children: see [A2]
>> and [A3] above.
>>
>> We can investigate those as well:
>>
>>> Shell> dh -d -v A2
>>> A2: 7EF49B58
>>> ManagedNetwork
>>>Controller Name: MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x806, 
>>> VlanId=0)
>>>Device Path: 
>>>Controller Type: BUS
>>>Configuration  : NO
>>>Diagnostics: NO
>>>Managed by :
>>>  Drv[71]  : ARP Network Service Driver
>>>Parent Controllers :
>>>  Parent[A0]   : Virtio Network Device
>>>Child Controllers  :
>>>  Child[AB]: PXE Controller
>>
>> The first MNP child has been extracted / requested, from MNPSB, by the
>> ARP (SB) driver.
>>
>>> Shell> dh -d -v A3
>>> A3: 7EF56AD8
>>> ManagedNetwork
>>>Controller Name: MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x800, 
>>> VlanId=0)
>>>Device Path: 
>>>Controller Type: BUS
>>>Configuration  : NO
>>>Diagnostics: NO
>>>Managed by :
>>>  Drv[73]  : IP4 Network Service Driver
>>>Parent Controllers :
>>>  Parent[A0]   : Virtio Network Device
>>>Child Controllers  :
>>>  Child[A5]: IPv4 (SrcIP=0.0.0.0)
>>>  Child[A6]: IPv4 (SrcIP=0.0.0.0)
>>>  Child[A8]: IPv4 (Not started)
>>>  Child[AA]: IPv4 (SrcIP=0.0.0.0)
>>>  Child[AD]: PXE Controller
>>>  Child[AE]: IPv4 (Not started)
>>>  Child[B1]: IPv4 (Not started)
>>>  Child[B3]: IPv4 (Not started)
>>>  Child[B7]: IPv4 (Not started)
>>
>> The other MNP child has been extracted / requested, from MNPSB, by the
>> IPv4 (SB) driver.
>>
>> Now, assuming GRUB wants Ethernet packet level access, this is exactly
>> what GRUB should do too: locate MNPSB, and ask it for another MNP
>> instance. That MNP instance will be de

[edk2] [PATCH] ShellPkg: Print error message when Shell set environment variable fail.

[Qiu Shumin]

If you try to 'set' a read only environment variable and it fails without 
printing any information.
This patch add error message printing when 'set' environment variable fails.

Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c  |   7 ++-
 .../UefiShellLevel2CommandsLib.uni | Bin 109570 -> 109742 bytes
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
index 45948e1..d5e6a08 100644
--- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
+++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
@@ -2,7 +2,7 @@
   Main file for attrib shell level 2 function.
 
   (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
-  Copyright (c) 2009 - 2010, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -141,6 +141,11 @@ ShellCommandRunSet (
 // assigning one
 //
 Status = ShellSetEnvironmentVariable(KeyName, Value, 
ShellCommandLineGetFlag(Package, L"-v"));
+if (EFI_ERROR(Status)) {
+  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SET_ERROR_SET), 
gShellLevel2HiiHandle, L"set", KeyName);
+  ShellStatus = (SHELL_STATUS) (Status & (~MAX_BIT));
+}
+
   } else {
 if (KeyName != NULL) {
   //
diff --git 
a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.uni 
b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.uni
index 
29563d2e21737be3c84a7e3413596a4fc8e0850b..cc2c33cda4a6bf1c4f5dbc8527dfaaab5185ca53
 100644
GIT binary patch
delta 93
zcmZp=!M5%u+k_{KrW>CgSD0+TAu%~mo`c_&AqWWlfjFKan89_jqps-W2b@Ne6F6B!
t6B&{iau`w>6c|bv@_}SAkXM8@X?uwhqg59Gwb%>C

-- 
1.9.5.msysgit.1

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

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

[Laszlo Ersek]

Mike,

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

I found that this version of PiSmmCpuDxeSmm depends on
CpuExceptionHandlerLib (Quark's doesn't).

The following interfaces from the library class are called:
- InitializeCpuExceptionHandlers()
- RegisterCpuInterruptHandler()

I think this makes sense. The call sites are:

  PiCpuSmmEntry
InitializeSmmIdt
  InitializeCpuExceptionHandlers

  SmmRestoreCpu
InitializeCpuExceptionHandlers

  SmmRegisterExceptionHandler == mSmmCpuService.RegisterExceptionHandler
RegisterCpuInterruptHandler

What I don't understand though is why the CpuExceptionHandlerLib class
is resolved to a NULL instance, in "UefiCpuPkg/UefiCpuPkg.dsc":


CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf

OVMF uses the following non-null instances (for the appropriate module
types):

- UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
- UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf

and as far as I remember, these exception handler library instances
print, by default, those fault information dumps (to the serial port)
that are very helpful for debugging incorrect pointer references and the
like.

So why doesn't this module use the corresponding SMM driver instance:

- UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf

and why does it use a NULL instance instead?

I realize that this module has its own fault info dumping facility
(called SmiPFHandler(), specific to Ia32 vs. X64), similarly to the
version in Quark. That handler calls DumpModuleInfoByIp(), which should
do what I like to have -- helpful location info.

However, SmiPFHandler() is registered with SmmRegisterExceptionHandler()
-- since PcdCpuSmmProfileEnable defaults to FALSE --, and that call
ultimately ends up in CpuExceptionHandlerLib. See the third call tree
excerpt at the top -- in total, we have:

SmmInitPageTable()
  SmmRegisterExceptionHandler(SmiPFHandler)
RegisterCpuInterruptHandler(SmiPFHandler)
  // implemented by CpuExceptionHandlerLib

Now, given that the CpuExceptionHandlerLib instance is the Null one here
(according to UefiCpuPkg/UefiCpuPkg.dsc), this PF handler will actually
*not* be installed. Is that your intent?

I don't think so. Your patch doesn't seem to affect the
CpuExceptionHandlerLib resolutions in any way; therefore I believe this
is an omission in the patch.

And, I think it doesn't only affect PiSmmCpuDxeSmm, but also SecCore
(which you added in patch 4/7 of this series).

On the other hand... I can see a preexistent client of
CpuExceptionHandlerLib in UefiCpuPkg: CpuDxe. (Of type DXE_DRIVER.)
Since the default Null resolution affects that module too, I'm now
inclined to think that maybe this is all intentional *within* UefiCpuPkg.

Either way, I'll go ahead and resolve CpuExceptionHandlerLib to
SmmCpuExceptionHandlerLib, for DXE_SMM_DRIVER modules, in OVMF. That
should be consistent with the current resolutions we have for other (SEC
/ PEIM / DXE_DRIVER / ...) modules already.

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

Re: [edk2] [Shell] input redirection from ASCII file

[Carsey, Jaben]

18452 (Sep 14) was supposed to address this issue.  Is your tree before or 
after that revision?

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Felix Poludov
> Sent: Thursday, October 08, 2015 7:52 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Shell] input redirection from ASCII file
> Importance: High
> 
> We're facing issues with the input redirection in shell (specifically with the
> input redirection from ASCII file).
> I'm wondering if anybody faced similar issues, or perhaps, Shell developers
> can provide some insights.
> 
> According to Shell specification (section 3.4.4.2) shell supports input
> redirection using the following syntax:
> 'Command <  filename' to redirect standard input from a Unicode file.
> 'Command  
> Here is the e-mail from one of our developers describing the issues we faced
> and workarounds we came up with:
> 
> =
> I faced an issue with input redirection in shell.
> It is working with Unicode file, but not working with ASCII file.
> 
> I tried to experiment with the "ls -b" command.
> The command prints one screen and requests user confirmation to continue
> ("Press ENTER to continue or "Q" break:").
> I created a Unicode file 1.txt which contains only "q".
> When I use command "ls -b < 1.txt" the command behaves as expected:
> prints a single screen and exists as if I pressed "q".
> When I converted the same file to ASCII and tried to run "ls -b  command, the command didn't work as expected.
> After displaying the first screen the command printed the message "Press
> ENTER to continue or "Q" break:" numerous times (about 20) and finally
> exited without reading the "q" key.
> 
> I made a fix in FileInterfaceFileRead function in FileHandleWrappers.c file
> (see the patch below).
> The function reads ASCII input string and converts it to a Unicode string 
> using
> UnicodeSPrint function:
> UnicodeSPrint(Buffer, *BufferSize, L"%a", AsciiBuffer);
> 
> The problem is that the *BufferSize that is coming to a function as an input
> parameter is not large enough to add a NULL terminator.
> In case of "ls -b" command, the *BufferSize is 2,  and UnicodeSPrint
> produces a blank string.
> I tried to use UnicodeSPrint with a temporary buffer that is large enough for
> a NULL terminator. Once string is converted I use CopyMem to copy
> data(excluding NULL terminator) to the original Buffer.
> These changes resolved the original problem (the redirection from ASCII file
> worked fine); however, I noticed another problem.
> If 1.txt ASCII file contains multiple characters, for example "abcdefg" each
> even character is skipped (using the same command  "ls -b  result is as if user pressed a, c, e, g characters on each "Press ENTER to
> continue or "Q" break:" request.
> 
> I found out that this is because size passed to
> (((EFI_FILE_PROTOCOL_FILE*)This)->Orig-
> >Read(((EFI_FILE_PROTOCOL_FILE*)This)->Orig, &Size, AsciiBuffer));
> function is equal to a total Unicode buffer size, which means the function 
> will
> read more ASCII characters that can actually fit into a Unicode buffer(twice 
> as
> much).
> After setting  Size to a half of the Unicode buffer size (*BufferSize/2) the
> problem was fixed; however, another problem arose: it looks like content of
> the redirection file affects the redirection behavior.
> For example having "q"  will results in reading all characters including 
> q.
> While having "acdeq" will result in successfully reading only a and c and
> throwing a lot of "Press ENTER to continue or "Q" break:" messages after that
> like it was described in the beginning.
> 
> Here is the modifications I've made:
> 
> diff --git a/ShellPkg/Application/Shell/FileHandleWrappers.c
> b/ShellPkg/Application/Shell/FileHandleWrappers.c
> index 18b6c3e..8903c50 100644
> --- a/ShellPkg/Application/Shell/FileHandleWrappers.c
> +++ b/ShellPkg/Application/Shell/FileHandleWrappers.c
> @@ -1671,7 +1671,9 @@ FileInterfaceFileRead(
>)
> {
>CHAR8   *AsciiBuffer;
> +  VOID   *TmpBuf;
>UINTN   Size;
> +  UINTN   Number = 0;
>EFI_STATUS  Status;
>if (((EFI_FILE_PROTOCOL_FILE*)This)->Unicode) {
>  //
> @@ -1683,9 +1685,22 @@ FileInterfaceFileRead(
>  // Ascii
>  //
>  AsciiBuffer = AllocateZeroPool((Size = *BufferSize));
> +Size = *BufferSize/2;
>  Status = (((EFI_FILE_PROTOCOL_FILE*)This)->Orig-
> >Read(((EFI_FILE_PROTOCOL_FILE*)This)->Orig, &Size, AsciiBuffer));
> -UnicodeSPrint(Buffer, *BufferSize, L"%a", AsciiBuffer);
> +if (!EFI_ERROR(Status))
> +{
> +  TmpBuf = AllocateZeroPool((*BufferSize + 2)); //UnicodeSPrint adds null
> terminator to any output so we need a bigger buffer
> +  Number = UnicodeSPrint(TmpBuf, *BufferSize + 2, L"%a", AsciiBuffer);
> +  if (Number)
> + CopyMem (Buffer, TmpBuf, *BufferSize); //Copy output to final
> destination without null terminator.
> +  FreePool(TmpBuf);
> +}

Re: [edk2] [PATCH] ShellPkg: Print error message when Shell set environment variable fail.

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Qiu Shumin
> Sent: Friday, October 09, 2015 6:16 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Qiu, Shumin
> 
> Subject: [edk2] [PATCH] ShellPkg: Print error message when Shell set
> environment variable fail.
> Importance: High
> 
> If you try to 'set' a read only environment variable and it fails without 
> printing
> any information.
> This patch add error message printing when 'set' environment variable fails.
> 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin 
> ---
>  ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c  |   7 ++-
>  .../UefiShellLevel2CommandsLib.uni | Bin 109570 -> 109742 
> bytes
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
> index 45948e1..d5e6a08 100644
> --- a/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
> +++ b/ShellPkg/Library/UefiShellLevel2CommandsLib/Set.c
> @@ -2,7 +2,7 @@
>Main file for attrib shell level 2 function.
> 
>(C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> -  Copyright (c) 2009 - 2010, Intel Corporation. All rights reserved.
> +  Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at
> @@ -141,6 +141,11 @@ ShellCommandRunSet (
>  // assigning one
>  //
>  Status = ShellSetEnvironmentVariable(KeyName, Value,
> ShellCommandLineGetFlag(Package, L"-v"));
> +if (EFI_ERROR(Status)) {
> +  ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_SET_ERROR_SET),
> gShellLevel2HiiHandle, L"set", KeyName);
> +  ShellStatus = (SHELL_STATUS) (Status & (~MAX_BIT));
> +}
> +
>} else {
>  if (KeyName != NULL) {
>//
> diff --git
> a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.uni
> b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
> Lib.uni
> index
> 29563d2e21737be3c84a7e3413596a4fc8e0850b..cc2c33cda4a6bf1c4f5dbc8527
> dfaaab5185ca53 100644
> GIT binary patch
> delta 93
> zcmZp=!M5%u+k_{KrW>CgSD0+TAu%~mo`c_&AqWWlfjFKan89_jqps-
> W2b@Ne6F6B!
> t6B&{iau`w>6c|bv@_}SAkX 
> delta 27
> jcmZ2?ldb6n+k_{KCL5m~SD3s(Q>M8@X?uwhqg59Gwb%>C
> 
> --
> 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 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[Kinney, Michael D]

Laszlo,

Thanks for the feedback.  I agree I need to update UefiCpuPkg DSC file.

Mike

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Friday, October 09, 2015 6:57 AM
>To: Kinney, Michael D
>Cc: edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module
>
>Mike,
>
>On 10/05/15 01:57, Michael Kinney wrote:
>> Add module that initializes a CPU for the SMM envirnment and
>> installs the first level SMI handler.  This module along with the
>> SMM IPL and SMM Core provide the services required for
>> DXE_SMM_DRIVERS to register hardware and software SMI handlers.
>>
>> CPU specific features are abstracted through the SmmCpuFeaturesLib
>>
>> Platform specific features are abstracted through the
>> SmmCpuPlatformHookLib
>>
>> Several PCDs are added to enable/disable features and configure
>> settings for the PiSmmCpuDxeSmm module
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney 
>> ---
>
>I found that this version of PiSmmCpuDxeSmm depends on
>CpuExceptionHandlerLib (Quark's doesn't).
>
>The following interfaces from the library class are called:
>- InitializeCpuExceptionHandlers()
>- RegisterCpuInterruptHandler()
>
>I think this makes sense. The call sites are:
>
>  PiCpuSmmEntry
>InitializeSmmIdt
>  InitializeCpuExceptionHandlers
>
>  SmmRestoreCpu
>InitializeCpuExceptionHandlers
>
>  SmmRegisterExceptionHandler ==
>mSmmCpuService.RegisterExceptionHandler
>RegisterCpuInterruptHandler
>
>What I don't understand though is why the CpuExceptionHandlerLib class
>is resolved to a NULL instance, in "UefiCpuPkg/UefiCpuPkg.dsc":
>
>
>CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNul
>l/CpuExceptionHandlerLibNull.inf
>
>OVMF uses the following non-null instances (for the appropriate module
>types):
>
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.i
>nf
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>
>and as far as I remember, these exception handler library instances
>print, by default, those fault information dumps (to the serial port)
>that are very helpful for debugging incorrect pointer references and the
>like.
>
>So why doesn't this module use the corresponding SMM driver instance:
>
>-
>UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.in
>f
>
>and why does it use a NULL instance instead?

Good point.  The DSC file in the UefiCpuPkg is there to test the build of the
Modules/libraries, so the specific lib instance from another package is not
critical.  I agree it makes sense to put in the preferred lib mappings is 
possible
So I will update the DSC file for UefiCpuPkg to use the correct 
CpuExceptionHandlerLib for each module type.

>
>I realize that this module has its own fault info dumping facility
>(called SmiPFHandler(), specific to Ia32 vs. X64), similarly to the
>version in Quark. That handler calls DumpModuleInfoByIp(), which should
>do what I like to have -- helpful location info.
>
>However, SmiPFHandler() is registered with SmmRegisterExceptionHandler()
>-- since PcdCpuSmmProfileEnable defaults to FALSE --, and that call
>ultimately ends up in CpuExceptionHandlerLib. See the third call tree
>excerpt at the top -- in total, we have:
>
>SmmInitPageTable()
>  SmmRegisterExceptionHandler(SmiPFHandler)
>RegisterCpuInterruptHandler(SmiPFHandler)
>  // implemented by CpuExceptionHandlerLib
>
>Now, given that the CpuExceptionHandlerLib instance is the Null one here
>(according to UefiCpuPkg/UefiCpuPkg.dsc), this PF handler will actually
>*not* be installed. Is that your intent?
>
>I don't think so. Your patch doesn't seem to affect the
>CpuExceptionHandlerLib resolutions in any way; therefore I believe this
>is an omission in the patch.
>
>And, I think it doesn't only affect PiSmmCpuDxeSmm, but also SecCore
>(which you added in patch 4/7 of this series).
>
>On the other hand... I can see a preexistent client of
>CpuExceptionHandlerLib in UefiCpuPkg: CpuDxe. (Of type DXE_DRIVER.)
>Since the default Null resolution affects that module too, I'm now
>inclined to think that maybe this is all intentional *within* UefiCpuPkg.
>
>Either way, I'll go ahead and resolve CpuExceptionHandlerLib to
>SmmCpuExceptionHandlerLib, for DXE_SMM_DRIVER modules, in OVMF. That
>should be consistent with the current resolutions we have for other (SEC
>/ PEIM / DXE_DRIVER / ...) modules already.

Yes.  A platform specific DSC must use the right lib mapping based on
module type.  

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

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

[Bjorge, Erik C]

The patch has some trailing white spaces but other than that it works fine.

Reviewed-by: Erik Bjorge 

-Original Message-
From: Justen, Jordan L 
Sent: Wednesday, October 7, 2015 7:53 PM
To: edk2-devel@lists.01.org
Cc: Justen, Jordan L ; Bjorge, Erik C 
; Zhu, Yonghong ; Gao, Liming 

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

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

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

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

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

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

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

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

  python PatchCheck.py HEAD~5..

Or, a shortcut (like git log):

  python PatchCheck.py -5

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

The --silent option enables silent operation.

The script supports python 2.7 and python 3.

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

diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py 
new file mode 100644 index 000..340a997
--- /dev/null
+++ b/BaseTools/Scripts/PatchCheck.py
@@ -0,0 +1,607 @@
+## @file
+#  Check a patch for various format issues # #  Copyright (c) 2015, 
+Intel Corporation. All rights reserved. # #  This program and the 
+accompanying materials are licensed and made #  available under the 
+terms and conditions of the BSD License which #  accompanies this 
+distribution. The full text of the license may be #  found at 
+http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
+#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER #  
+EXPRESS OR IMPLIED.
+#
+
+from __future__ import print_function
+
+VersionNumber = '0.1'
+__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
+
+import email
+import argparse
+import os
+import re
+import subprocess
+import sys
+
+class Verbose:
+SILENT, ONELINE, NORMAL = range(3)
+level = NORMAL
+
+class CommitMessageCheck:
+"""Checks the contents of a git commit message."""
+
+def __init__(self, subject, message):
+self.ok = True
+
+if subject is None and  message is None:
+self.error('Commit message is missing!')
+return
+
+self.subject = subject
+self.msg = message
+
+self.check_contributed_under()
+self.check_signed_off_by()
+self.check_misc_signatures()
+self.check_overall_format()
+self.report_message_result()
+
+url = 
'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
+
+def report_message_result(self):
+if Verbose.level < Verbose.NORMAL:
+return
+if self.ok:
+# All checks passed
+return_code = 0
+print('The commit message format passed all checks.')
+else:
+return_code = 1
+if not self.ok:
+print(self.url)
+
+def error(self, *err):
+if self.ok and Verbose.level > Verbose.ONELINE:
+print('The commit message format is not valid:')
+self.ok = False
+if Verbose.level < Verbose.NORMAL:
+return
+count = 0
+for line in err:
+prefix = (' *', '  ')[count > 0]
+print(prefix, line)
+count += 1
+
+def check_contributed_under(self):
+cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
+if self.msg.find(cu_msg) < 0:
+self.error('Missing Contributed-under! (Note: this must be ' +
+   'added by the code contributor!)')
+
+@staticmethod
+def make_signature_re(sig, re_input=False):
+if re_input:
+sub_re = sig
+else:
+sub_re = sig.replace('-', r'[-\s]+')
+re_str = (r'^(?P' + sub_re +
+  r')(\s*):(\s*)(?P\S.*?)(?:\s*)$')
+try:
+return re.compile(re_str, re.MULTILINE|re.IGNORECASE)
+except Exception:
+print("Tried to compile re:", re_str)
+raise
+
+sig_block_re = \
+re.compile(r'''^
+(?: (?P[^:]+) \s* : \s*
+

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

[Laszlo Ersek]

On 10/09/15 19:13, Bjorge, Erik C wrote:
> The patch has some trailing white spaces

Apparently, Jordan forgot to run the script on the patch that adds the
script! ;)

Laszlo

> but other than that it works fine.
> 
> Reviewed-by: Erik Bjorge 
> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Wednesday, October 7, 2015 7:53 PM
> To: edk2-devel@lists.01.org
> Cc: Justen, Jordan L ; Bjorge, Erik C 
> ; Zhu, Yonghong ; Gao, 
> Liming 
> Subject: [PATCH] BaseTools/Scripts: Add PatchCheck.py script
> 
> This script can be used to check some expected rules for EDK II patches. It 
> only works on git formatted patches.
> 
> It checks both the commit message and the lines that are added in the patch 
> diff.
> 
> In the commit message it verifies line lengths, signature formats, and the 
> Contributed-under tag.
> 
> In the patch, it checks that line endings are CRLF for all files that don't 
> have a .sh extension. It verifies that no trailing whitespace is present and 
> that tab characters are not used.
> 
> Patch contributors should use this script prior to submitting their patches. 
> Package maintainers can also use it to verify incoming patches.
> 
> It can also be run by specifying a git revision list, so actual patch files 
> are not always required.
> 
> For example, to checkout this last 5 patches in your git branch you can run:
> 
>   python PatchCheck.py HEAD~5..
> 
> Or, a shortcut (like git log):
> 
>   python PatchCheck.py -5
> 
> The --oneline option works similar to git log --oneline.
> 
> The --silent option enables silent operation.
> 
> The script supports python 2.7 and python 3.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> Cc: Erik Bjorge 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> ---
>  BaseTools/Scripts/PatchCheck.py | 607 
> 
>  1 file changed, 607 insertions(+)
>  create mode 100644 BaseTools/Scripts/PatchCheck.py
> 
> diff --git a/BaseTools/Scripts/PatchCheck.py 
> b/BaseTools/Scripts/PatchCheck.py new file mode 100644 index 000..340a997
> --- /dev/null
> +++ b/BaseTools/Scripts/PatchCheck.py
> @@ -0,0 +1,607 @@
> +## @file
> +#  Check a patch for various format issues # #  Copyright (c) 2015, 
> +Intel Corporation. All rights reserved. # #  This program and the 
> +accompanying materials are licensed and made #  available under the 
> +terms and conditions of the BSD License which #  accompanies this 
> +distribution. The full text of the license may be #  found at 
> +http://opensource.org/licenses/bsd-license.php
> +#
> +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> +#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER #  
> +EXPRESS OR IMPLIED.
> +#
> +
> +from __future__ import print_function
> +
> +VersionNumber = '0.1'
> +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
> +
> +import email
> +import argparse
> +import os
> +import re
> +import subprocess
> +import sys
> +
> +class Verbose:
> +SILENT, ONELINE, NORMAL = range(3)
> +level = NORMAL
> +
> +class CommitMessageCheck:
> +"""Checks the contents of a git commit message."""
> +
> +def __init__(self, subject, message):
> +self.ok = True
> +
> +if subject is None and  message is None:
> +self.error('Commit message is missing!')
> +return
> +
> +self.subject = subject
> +self.msg = message
> +
> +self.check_contributed_under()
> +self.check_signed_off_by()
> +self.check_misc_signatures()
> +self.check_overall_format()
> +self.report_message_result()
> +
> +url = 
> 'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
> +
> +def report_message_result(self):
> +if Verbose.level < Verbose.NORMAL:
> +return
> +if self.ok:
> +# All checks passed
> +return_code = 0
> +print('The commit message format passed all checks.')
> +else:
> +return_code = 1
> +if not self.ok:
> +print(self.url)
> +
> +def error(self, *err):
> +if self.ok and Verbose.level > Verbose.ONELINE:
> +print('The commit message format is not valid:')
> +self.ok = False
> +if Verbose.level < Verbose.NORMAL:
> +return
> +count = 0
> +for line in err:
> +prefix = (' *', '  ')[count > 0]
> +print(prefix, line)
> +count += 1
> +
> +def check_contributed_under(self):
> +cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
> +if self.msg.find(cu_msg) < 0:
> +self.error('Missing Contributed-under! (Note: this must be ' +
> +   'added by the code contributor!)')
> +
> +@staticmethod
> +def make_signature_re(sig, re_input=False):
> +if re_input:
> +sub_re = sig
> + 

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

[Jordan Justen]

On 2015-10-09 10:57:40, Laszlo Ersek wrote:
> On 10/09/15 19:13, Bjorge, Erik C wrote:
> > The patch has some trailing white spaces
> 
> Apparently, Jordan forgot to run the script on the patch that adds the
> script! ;)

I ran the script on the patch, and it didn't flag any trailing
whitespace. So, if there is trailing whitespace in the patch, then
there is a bug in the script.

I also tried using my editor to cleanup any tailing whitespace, and it
didn't seem to locate any.

Can either of you point out a line with trailing whitespace in the
patch?

-Jordan

> > but other than that it works fine.
> > 
> > Reviewed-by: Erik Bjorge 
> > 
> > -Original Message-
> > From: Justen, Jordan L 
> > Sent: Wednesday, October 7, 2015 7:53 PM
> > To: edk2-devel@lists.01.org
> > Cc: Justen, Jordan L ; Bjorge, Erik C 
> > ; Zhu, Yonghong ; Gao, 
> > Liming 
> > Subject: [PATCH] BaseTools/Scripts: Add PatchCheck.py script
> > 
> > This script can be used to check some expected rules for EDK II patches. It 
> > only works on git formatted patches.
> > 
> > It checks both the commit message and the lines that are added in the patch 
> > diff.
> > 
> > In the commit message it verifies line lengths, signature formats, and the 
> > Contributed-under tag.
> > 
> > In the patch, it checks that line endings are CRLF for all files that don't 
> > have a .sh extension. It verifies that no trailing whitespace is present 
> > and that tab characters are not used.
> > 
> > Patch contributors should use this script prior to submitting their 
> > patches. Package maintainers can also use it to verify incoming patches.
> > 
> > It can also be run by specifying a git revision list, so actual patch files 
> > are not always required.
> > 
> > For example, to checkout this last 5 patches in your git branch you can run:
> > 
> >   python PatchCheck.py HEAD~5..
> > 
> > Or, a shortcut (like git log):
> > 
> >   python PatchCheck.py -5
> > 
> > The --oneline option works similar to git log --oneline.
> > 
> > The --silent option enables silent operation.
> > 
> > The script supports python 2.7 and python 3.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jordan Justen 
> > Cc: Erik Bjorge 
> > Cc: Yonghong Zhu 
> > Cc: Liming Gao 
> > ---
> >  BaseTools/Scripts/PatchCheck.py | 607 
> > 
> >  1 file changed, 607 insertions(+)
> >  create mode 100644 BaseTools/Scripts/PatchCheck.py
> > 
> > diff --git a/BaseTools/Scripts/PatchCheck.py 
> > b/BaseTools/Scripts/PatchCheck.py new file mode 100644 index 
> > 000..340a997
> > --- /dev/null
> > +++ b/BaseTools/Scripts/PatchCheck.py
> > @@ -0,0 +1,607 @@
> > +## @file
> > +#  Check a patch for various format issues # #  Copyright (c) 2015, 
> > +Intel Corporation. All rights reserved. # #  This program and the 
> > +accompanying materials are licensed and made #  available under the 
> > +terms and conditions of the BSD License which #  accompanies this 
> > +distribution. The full text of the license may be #  found at 
> > +http://opensource.org/licenses/bsd-license.php
> > +#
> > +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > +#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER #  
> > +EXPRESS OR IMPLIED.
> > +#
> > +
> > +from __future__ import print_function
> > +
> > +VersionNumber = '0.1'
> > +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights 
> > reserved."
> > +
> > +import email
> > +import argparse
> > +import os
> > +import re
> > +import subprocess
> > +import sys
> > +
> > +class Verbose:
> > +SILENT, ONELINE, NORMAL = range(3)
> > +level = NORMAL
> > +
> > +class CommitMessageCheck:
> > +"""Checks the contents of a git commit message."""
> > +
> > +def __init__(self, subject, message):
> > +self.ok = True
> > +
> > +if subject is None and  message is None:
> > +self.error('Commit message is missing!')
> > +return
> > +
> > +self.subject = subject
> > +self.msg = message
> > +
> > +self.check_contributed_under()
> > +self.check_signed_off_by()
> > +self.check_misc_signatures()
> > +self.check_overall_format()
> > +self.report_message_result()
> > +
> > +url = 
> > 'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
> > +
> > +def report_message_result(self):
> > +if Verbose.level < Verbose.NORMAL:
> > +return
> > +if self.ok:
> > +# All checks passed
> > +return_code = 0
> > +print('The commit message format passed all checks.')
> > +else:
> > +return_code = 1
> > +if not self.ok:
> > +print(self.url)
> > +
> > +def error(self, *err):
> > +if self.ok and Verbose.level > Verbose.ONELINE:
> > +print('The commit message format is not valid:')
> > +self.ok = False
> > + 

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

[Jordan Justen]

On 2015-10-08 15:22:08, Laszlo Ersek wrote:
> On 10/08/15 04:53, Jordan Justen wrote:
> > This script can be used to check some expected rules for EDK II
> > patches. It only works on git formatted patches.
> > 
> > It checks both the commit message and the lines that are added in the
> > patch diff.
> > 
> > In the commit message it verifies line lengths, signature formats, and
> > the Contributed-under tag.
> > 
> > In the patch, it checks that line endings are CRLF for all files that
> > don't have a .sh extension. It verifies that no trailing whitespace is
> > present and that tab characters are not used.
> 
> Yay! :)
> 
> Immediate RFE: can it enforce a line length of 79 characters for lines
> that a patch adds, to C or assembly source code (based on filename
> suffix)? ;)

I would also like to add this. But, I thought it might be too
controversial for a first pass. (Despite the fact that it is part of
the coding standard.)

> And reject non-ASCII characters in the same?

This one I'd like to hold off on just because I don't want to spend
the time implement it just now. :)

-Jordan

> Anyway, those are just ideas, and ideas are a dime a dozen. :)
> 
> Thanks
> Laszlo
> 
> > 
> > Patch contributors should use this script prior to submitting their
> > patches. Package maintainers can also use it to verify incoming
> > patches.
> > 
> > It can also be run by specifying a git revision list, so actual patch
> > files are not always required.
> > 
> > For example, to checkout this last 5 patches in your git branch you
> > can run:
> > 
> >   python PatchCheck.py HEAD~5..
> > 
> > Or, a shortcut (like git log):
> > 
> >   python PatchCheck.py -5
> > 
> > The --oneline option works similar to git log --oneline.
> > 
> > The --silent option enables silent operation.
> > 
> > The script supports python 2.7 and python 3.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jordan Justen 
> > Cc: Erik Bjorge 
> > Cc: Yonghong Zhu 
> > Cc: Liming Gao 
> > ---
> >  BaseTools/Scripts/PatchCheck.py | 607 
> > 
> >  1 file changed, 607 insertions(+)
> >  create mode 100644 BaseTools/Scripts/PatchCheck.py
> > 
> > diff --git a/BaseTools/Scripts/PatchCheck.py 
> > b/BaseTools/Scripts/PatchCheck.py
> > new file mode 100644
> > index 000..340a997
> > --- /dev/null
> > +++ b/BaseTools/Scripts/PatchCheck.py
> > @@ -0,0 +1,607 @@
> > +## @file
> > +#  Check a patch for various format issues
> > +#
> > +#  Copyright (c) 2015, Intel Corporation. All rights reserved.
> > +#
> > +#  This program and the accompanying materials are licensed and made
> > +#  available under the terms and conditions of the BSD License which
> > +#  accompanies this distribution. The full text of the license may be
> > +#  found at http://opensource.org/licenses/bsd-license.php
> > +#
> > +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > +#  BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> > +#  EXPRESS OR IMPLIED.
> > +#
> > +
> > +from __future__ import print_function
> > +
> > +VersionNumber = '0.1'
> > +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights 
> > reserved."
> > +
> > +import email
> > +import argparse
> > +import os
> > +import re
> > +import subprocess
> > +import sys
> > +
> > +class Verbose:
> > +SILENT, ONELINE, NORMAL = range(3)
> > +level = NORMAL
> > +
> > +class CommitMessageCheck:
> > +"""Checks the contents of a git commit message."""
> > +
> > +def __init__(self, subject, message):
> > +self.ok = True
> > +
> > +if subject is None and  message is None:
> > +self.error('Commit message is missing!')
> > +return
> > +
> > +self.subject = subject
> > +self.msg = message
> > +
> > +self.check_contributed_under()
> > +self.check_signed_off_by()
> > +self.check_misc_signatures()
> > +self.check_overall_format()
> > +self.report_message_result()
> > +
> > +url = 
> > 'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
> > +
> > +def report_message_result(self):
> > +if Verbose.level < Verbose.NORMAL:
> > +return
> > +if self.ok:
> > +# All checks passed
> > +return_code = 0
> > +print('The commit message format passed all checks.')
> > +else:
> > +return_code = 1
> > +if not self.ok:
> > +print(self.url)
> > +
> > +def error(self, *err):
> > +if self.ok and Verbose.level > Verbose.ONELINE:
> > +print('The commit message format is not valid:')
> > +self.ok = False
> > +if Verbose.level < Verbose.NORMAL:
> > +return
> > +count = 0
> > +for line in err:
> > +prefix = (' *', '  ')[count > 0]
> > +print(prefix, line)
> > +count += 1
> > +
> > +def check_cont

[edk2] [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Laszlo Ersek]

The

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe

driver applies any MTRR changes to APs, if the EFI_MP_SERVICES_PROTOCOL is
available. We should do the same.

Additionally, the broadcast should occur at MP startup as well, not only
when MTRR settings are changed. The inspiration is taken from

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

(see the EarlyMpInit() function and its call sites in
"ProcessorConfig.c").

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

Notes:
v2:
- This patch replaces the following patches from v1:
  - UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory
block
  - UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
  - UefiCpuPkg: CpuDxe: sync MTRR settings to APs at MP startup
  - UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL when there's no
AP

  The first v1 patch was deemed inappropriate for general use, and Mike
  suggested a good alternative for OVMF (=> grab MTRR settings in
  CpuS3DataDxe at EndOfDxe).

  The second and third v1 patches are now squashed together into this v2
  patch; they are small and belong together logically.

  The fourth v1 patch is redundant now; the same has been covered by
  Mike.

 UefiCpuPkg/CpuDxe/CpuMp.h  | 13 
 UefiCpuPkg/CpuDxe/CpuDxe.c | 26 +++
 UefiCpuPkg/CpuDxe/CpuMp.c  | 34 +++-
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.h b/UefiCpuPkg/CpuDxe/CpuMp.h
index d2866e4..503f3ae 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.h
+++ b/UefiCpuPkg/CpuDxe/CpuMp.h
@@ -643,5 +643,18 @@ ResetApStackless (
   IN UINT32 ProcessorId
   );
 
+/**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  );
+
 #endif // _CPU_MP_H_
 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index c9df4e1..daf97bd 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -350,6 +350,9 @@ CpuSetMemoryAttributes (
 {
   RETURN_STATUS Status;
   MTRR_MEMORY_CACHE_TYPECacheType;
+  EFI_STATUSMpStatus;
+  EFI_MP_SERVICES_PROTOCOL  *MpService;
+  MTRR_SETTINGS MtrrSettings;
 
   if (!IsMtrrSupported ()) {
 return EFI_UNSUPPORTED;
@@ -405,6 +408,29 @@ CpuSetMemoryAttributes (
  CacheType
  );
 
+  if (!RETURN_ERROR (Status)) {
+MpStatus = gBS->LocateProtocol (
+  &gEfiMpServiceProtocolGuid,
+  NULL,
+  (VOID **)&MpService
+  );
+//
+// Synchronize the update with all APs
+//
+if (!EFI_ERROR (MpStatus)) {
+  MtrrGetAllMtrrs (&MtrrSettings);
+  MpStatus = MpService->StartupAllAPs (
+  MpService,  // This
+  SetMtrrsFromBuffer, // Procedure
+  TRUE,   // SingleThread
+  NULL,   // WaitEvent
+  0,  // TimeoutInMicrosecsond
+  &MtrrSettings,  // ProcedureArgument
+  NULL// FailedCpuList
+  );
+  ASSERT (MpStatus == EFI_SUCCESS || MpStatus == EFI_NOT_STARTED);
+}
+  }
   return (EFI_STATUS) Status;
 }
 
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index da3686e..fbe43f5 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1626,6 +1626,22 @@ ExitBootServicesCallback (
 }
 
 /**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  )
+{
+  MtrrSetAllMtrrs (Buffer);
+}
+
+/**
   Initialize Multi-processor support.
 
 **/
@@ -1634,7 +1650,8 @@ InitializeMpSupport (
   VOID
   )
 {
-  EFI_STATUS Status;
+  EFI_STATUSStatus;
+  MTRR_SETTINGS MtrrSettings;
 
   gMaxLogicalProcessorNumber = (UINTN) PcdGet32 
(PcdCpuMaxLogicalProcessorNumber);
   if (gMaxLogicalProcessorNumber < 1) {
@@ -1690,6 +1707,21 @@ InitializeMpSupport (
   //
   CollectBistDataFromHob ();
 
+  //
+  // Synchronize MTRR settings to APs.
+  //
+  MtrrGetAllMtrrs (&MtrrSettings);
+  Status = mMpServicesTemplate.StartupAllAPs (
+ &mMpServicesTemplate, // This
+ SetMtrrsFromBuffer,   // Procedure
+   

[edk2] [PATCH v2 01/41] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

[Laszlo Ersek]

From: Michael Kinney 

When only 1 CPU is detected and the max CPUs is greater than 1,
an ASSERT() is generated because the pages associated with the
AP stack have already been freed.  Only do this FreePages() call
if there is more than 1 CPU detected.

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

Notes:
v2:
- New in v2, but this is just a fixup from Mike on top of his series
  "[edk2] [PATCH 0/7] UefiCpuPkg: Add CPU SMM and SecCore". I'm
  including it here for completeness; the next version of Mike's series
  will contain it squashed-in.

 UefiCpuPkg/CpuDxe/CpuMp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 22a0d9d..da3686e 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1697,7 +1697,7 @@ InitializeMpSupport (
   );
   ASSERT_EFI_ERROR (Status);
 
-  if (mMpSystemData.NumberOfProcessors < gMaxLogicalProcessorNumber) {
+  if (mMpSystemData.NumberOfProcessors > 1 && mMpSystemData.NumberOfProcessors 
< gMaxLogicalProcessorNumber) {
 if (mApStackStart != NULL) {
   FreePages (mApStackStart, EFI_SIZE_TO_PAGES (
   (gMaxLogicalProcessorNumber - 
mMpSystemData.NumberOfProcessors) *
-- 
1.8.3.1


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

[edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

[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 de260e4..7872b6b 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -674,4 +674,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 8e82613..081fd84 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -681,4 +681,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 4df7de1..6f42869 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -679,4 +679,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   = IA32 X64
+#
+
+[

[edk2] [PATCH v2 13/41] OvmfPkg: pull in CpuIo2Smm driver

[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 1d918eb..0aae66d 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
@@ -696,4 +702,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 ac89bf6..e811b9d 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
@@ -703,4 +709,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 9de84bd..ca227ed 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
@@ -701,4 +707,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 @@ [Rule.Common.SMM_C

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

[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 v2 07/41] OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()

[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 a6d9616..0b11275 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 v2 05/41] OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer

[Laszlo Ersek]

The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).

DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.

Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.

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

Notes:
v2:
- PcdOvmfDecomprScratchEnd => PcdOvmfDecompressionScratchEnd [Jordan]
  
- SCRATCH => DECOMP_SCRATCH [Jordan]
  (same)

 OvmfPkg/OvmfPkg.dec   |  1 +
 OvmfPkg/OvmfPkgIa32.fdf   |  4 +-
 OvmfPkg/OvmfPkgIa32X64.fdf|  4 +-
 OvmfPkg/OvmfPkgX64.fdf|  4 +-
 OvmfPkg/Sec/SecMain.inf   |  1 +
 OvmfPkg/Sec/SecMain.c |  8 +++
 OvmfPkg/DecomprScratchEnd.fdf.inc | 72 
 OvmfPkg/OvmfPkg.fdf.inc   |  2 +
 8 files changed, 93 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f9decd3..3fab2af 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -110,6 +110,7 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 2581fdb..44e4a92 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 01f384a..67bfbe7 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 4ad89fb..6624789 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -78,7 +78,7 @@ [FD.OVMF_CODE]
 

 
 [FD.MEMFD]
-BaseAddress   = 0x80
+BaseAddress   = $(MEMFD_BASE_ADDRESS)
 Size  = 0xA0
 ErasePolarity = 1
 BlockSize = 0x1
@@ -384,6 +384,8 @@ [FV.FVMAIN_COMPACT]
}
  }
 
+!include DecomprScratchEnd.fdf.inc
+
 

 
 [Rule.Common.SEC]
diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index e4bbb33..2215dd9 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -69,6 +69,7 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
 
 [FeaturePcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index a773b6d..fc3b7a8 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -361,6 +361,14 @@ DecompressMemFvs (
 
   OutputBuffer = (VOID*) ((UINT8*)(UINTN) PcdGet32 (PcdOvmfDxeMemFvBase) + 
SIZE_1MB);
   ScratchBuffer = ALIGN_POINTER ((UINT8*) OutputBuffer + OutputBufferSize, 
SIZE_1MB);
+
+  DEBUG ((EFI_D_VERBOSE, "%a: O

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

[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 c2c7da9..4b1e68d 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
@@ -87,6 +88,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 
(PcdOvmfDxeMemFvSize);
+// Technically we could lay the perman

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

[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 0aae66d..10d00b9 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
@@ -460,6 +469,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 {
@@ -707,4 +719,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 e811b9d..8b02441 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
   LockBoxLib|OvmfPkg/Library/Loc

[edk2] [PATCH v2 12/41] OvmfPkg: pull in the SMM IPL and SMM core

[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 7872b6b..1d918eb 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
 
 

 #
@@ -675,4 +686,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 081fd84..ac89bf6 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
 
 

 #
@@ -682,4 +693,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 6f42869..9de84bd 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
+  
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
+  

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

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

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 
---
 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..da6967f 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|1|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 4b1e68d..dc77293 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 (FeaturePcdGet (PcdSmmSmramRequire)) {
+  UINT32 TsegSize;
+
+  TsegSize = FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
+  AddMemoryRangeHob (BASE_1MB, LowerMemorySize - TsegSize);
+  AddReservedMemoryBaseSizeHob (LowerMemorySize - TsegSize, TsegSize,
+TRUE);
+} else {
+  AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
+}
+
 if (UpperMemorySize != 0) {
   AddUntestedMemoryBaseSizeHob (BASE_4GB, UpperMemorySize);
 }
@@ -409,5 +426,20 @@ InitializeRamRegions (
   (UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize),
   mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
   );
+
+if (FeaturePcdGet (PcdSmmSmramRequire)) {
+  UINT32 TsegSize;
+
+  //
+  // Make sure the TSEG are

[edk2] [PATCH v2 18/41] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

[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 a86b62f..41650e8 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 2227e1c..676c99c 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 9ab9b01..d61eae9 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 v2 14/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

[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 (
-  &ImageHandle,
-  &gEfiLockBoxProtocolGuid, NULL,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
+  if (!FeaturePcdGet (PcdSmmSmramRequire)) {
+Status = gBS->InstallMultipleProtocolInterfaces (
+&ImageHandle,
+&gEfiLockBoxProtocolGuid, 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

[edk2] [PATCH v2 09/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Laszlo Ersek]

"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library
instance that implements the LockBoxLib library class with SMRAM access
for the PEI phase.

Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.

Said library instance can parse and access LockBox data itself (without
additional LockBox drivers) if the
EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() function returns
EFI_NOT_STARTED to it. However it requires that
EFI_PEI_SMM_COMMUNICATION_PPI exist at least. Also, PEI_SMM_ACCESS_PPI
must exist and work.

The load / installation order of S3Resume2Pei and SmmAccessPei is
indifferent. SmmAccessPei produces the GUIDed HOB during its installation
(which happens during PEI), but S3Resume2Pei accesses the HOB only when
the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc|   6 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   6 +
 OvmfPkg/OvmfPkgX64.dsc |   6 +
 OvmfPkg/OvmfPkgIa32.fdf|   3 +
 OvmfPkg/OvmfPkgIa32X64.fdf |   3 +
 OvmfPkg/OvmfPkgX64.fdf |   3 +
 OvmfPkg/SmmAccess/SmmAccessPei.inf |  70 +++
 OvmfPkg/SmmAccess/SmramInternal.h  |  89 
 OvmfPkg/SmmAccess/SmmAccessPei.c   | 446 
 OvmfPkg/SmmAccess/SmramInternal.c  | 187 
 10 files changed, 819 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 24747c9..f94df20 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -444,6 +444,12 @@ [Components]
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
+!endif
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 0ebc88b..01afff9 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -450,6 +450,12 @@ [Components.IA32]
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
+!endif
 
 [Components.X64]
   #
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 056c0c0..859d074 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -449,6 +449,12 @@ [Components]
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
+!if $(SMM_REQUIRE) == TRUE
+  OvmfPkg/SmmAccess/SmmAccessPei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
+!endif
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 44e4a92..650dab1 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -171,6 +171,9 @@ [FV.PEIFV]
 INF  OvmfPkg/PlatformPei/PlatformPei.inf
 INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
+!endif
 
 

 
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 67bfbe7..5830401 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -171,6 +171,9 @@ [FV.PEIFV]
 INF  OvmfPkg/PlatformPei/PlatformPei.inf
 INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
+!endif
 
 

 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 6624789..9dd6171 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -171,6 +171,9 @@ [FV.PEIFV]
 INF  OvmfPkg/PlatformPei/PlatformPei.inf
 INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+!if $(SMM_REQUIRE) == TRUE
+INF  OvmfPkg/SmmAccess/SmmAccessPei.inf
+!endif
 
 

 
diff --git a/OvmfPkg/SmmAccess/SmmAccessPei.inf 
b/OvmfPkg/SmmAccess/SmmAccessPei.inf
new file mode 100644
index 000..94eb6c9
--- /dev/null
+++ b/OvmfPkg/SmmAccess/SmmAccessPei.inf
@@ -0,0 +1,70 @@
+## @file
+# A PEIM with the following responsibilities:
+#
+# - provide SMRAM access by producing PEI_SMM_ACCESS_PPI,
+# - provide a simple EFI_PEI_SMM_COMMUNICATION_PPI (always returning
+#   EFI_NOT_STARTED),
+# - verify & configure the Q35 TSEG in the entry point,
+# - set aside the SMM_S3_RESUME_STATE object at the bottom of TSEG, and expose
+#   it via the gEfiAcpiVariableGuid GUIDed HOB.
+#
+# Copyright (C) 2013, 2015, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made available
+# und

[edk2] [PATCH v2 20/41] OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE

[Laszlo Ersek]

At this point we can enable building PiSmmCpuDxeSmm.

The SmmLib dependency is resolved to MdePkg's SmmLibNull instance. First,
this matches the resolution in "UefiCpuPkg/UefiCpuPkg.dsc". Second, from
this library class, PiSmmCpuDxeSmm calls the ClearSmi() interface only,
and that API is a no-op on Q35 anyway.

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 the
one implementation under UefiCpuPkg.

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 (especially with
regard to S3); the upcoming, trimmed down CpuMpDxe port (under the name
CpuS3DataDxe) will be necessary for that.

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

Notes:
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| 6 ++
 OvmfPkg/OvmfPkgIa32X64.dsc | 6 ++
 OvmfPkg/OvmfPkgX64.dsc | 6 ++
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 21 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index d8df8cc..3dc71cd 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -726,4 +726,10 @@ [Components]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
+  
SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index b26eb8b..35ad8fa 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -733,4 +733,10 @@ [Components.X64]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
+  
SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
+  }
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a7c803a..f9f4001 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -731,4 +731,10 @@ [Components]
 
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
   }
+  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
+
+  
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
+  SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
+  
SmmCpuFeaturesLib|UefiCpuPkg/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 a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index bceab15..b9fee36 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.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
+

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

[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 41650e8..d8df8cc 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -342,6 +342,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 676c99c..b26eb8b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -347,6 +347,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 d61eae9..a7c803a 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -347,6 +347,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 v2 04/41] OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table

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

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

Notes:
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 fce99fb..e4bbb33 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -67,3 +67,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 b7df549..a773b6d 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -698,8 +698,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)) {
+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, "%a: cleared BaseExtractGuidedSectionLib table\n",
+  __FUNCTION__));
+  }
+
   DEBUG ((EFI_D_INFO,
 "SecCoreStartupWithStack(0x%x, 0x%x)\n",
 (UINT32)(UINTN)BootFv,
-- 
1.8.3.1


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

[edk2] [PATCH v2 00/41] OvmfPkg: support SMM for better security (single VCPU, IA32)

[Laszlo Ersek]

In this version I've addressed the feedback I got for v1, plus I've
rebased the series on top of Mike's

  [edk2] [PATCH 0/7] UefiCpuPkg: Add CPU SMM and SecCore
  
http://news.gmane.org/find-root.php?message_id=1444003040-21292-1-git-send-email-michael.d.kin...@intel.com

The following v1 patches have been dropped altogether, thanks to Mike's
work, because PiSmmCpuDxeSmm belongs under UefiCpuPkg now:

  [PATCH 17/58] OvmfPkg: import PiSmmCpuDxeSmm from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  [PATCH 19/58] OvmfPkg: PiSmmCpuDxeSmm: eliminate CpuConfigLib linkage
dependency
  [PATCH 21/58] OvmfPkg: import SocketLga775Lib header from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  [PATCH 22/58] OvmfPkg: import SmmCpuPlatformHookLibNull from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  [PATCH 24/58] OvmfPkg: replace IA32FamilyCpuBasePkg.dec references
with OvmfPkg.dec
  [PATCH 25/58] OvmfPkg: replace gEfiCpuTokenSpaceGuid with
gQuarkPortCpuTokenSpaceGuid
  [PATCH 26/58] OvmfPkg: PiSmmCpuDxeSmm: fix namespace for
PcdCpuMaxLogicalProcessorNumber
  [PATCH 28/58] OvmfPkg: import three protocols from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  [PATCH 29/58] OvmfPkg: PiSmmCpuDxeSmm: fix warning about
UINT32-to-(VOID*) conversion
  [PATCH 30/58] OvmfPkg: PiSmmCpuDxeSmm: fix up pathname in include
directive
  [PATCH 32/58] OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.APState
  [PATCH 38/58] UefiCpuPkg: CpuDxe: optionally save MTRR settings to
AcpiNVS memory block
  [PATCH 41/58] UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL
when there's no AP
  [PATCH 45/58] OvmfPkg: QuarkPort/PiSmmCpuDxeSmm: hard-code CPU class
identification

The following patches are new in v2:

  [PATCH v2 01/41] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU
   detected
  [PATCH v2 18/41] OvmfPkg: resolve CpuExceptionHandlerLib for
   DXE_SMM_DRIVER modules

The other patches have been preserved, with or without changes
(significant or otherwise); in such cases, the changes, if any, are
noted per patch.

Public branch (including Mike's patches):


This version works on the same "functionality level" as v1 -- single
VCPU, Ia32, -nx, S3.

I tried multiple VCPU as well; unfortunately, it breaks down in
different spots, dependent on whether I use TCG or KVM. Namely, with
TCG, even the first StartupAllAPs() call (visible in "[PATCH v2 02/41]
UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs") gets stuck, whereas
with KVM, the SmmRelocateBases() call never completes in
"UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c".

Given that KVM gets past the first StartupAllAPs() call, I think TCG's
hang may be TCG's fault. And because Mike tested
"UefiCpuPkg/PiSmmCpuDxeSmm" on physical MP hardware, I tend to think
that KVM getting stuck in SmmRelocateBases() may be a KVM bug.

Cc: Paolo Bonzini 
Cc: Jordan Justen 
Cc: Michael Kinney 

Thanks
Laszlo

Laszlo Ersek (40):
  UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
  OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire
  OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler
table
  OvmfPkg: Sec: assert the build-time calculated end of the scratch
buffer
  OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set
  OvmfPkg: PlatformPei: allow caching in AddReservedMemoryBaseSizeHob()
  OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire
set
  OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI
  OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time
DXE
  OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
  OvmfPkg: pull in the SMM IPL and SMM core
  OvmfPkg: pull in CpuIo2Smm driver
  OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE
  OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox
  OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE
  OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules
  OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules
  OvmfPkg: set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection to
FALSE
  OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE
  OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe
  OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector
  OvmfPkg: QuarkPort/CpuS3DataDxe: handle IDT, GDT and MCE in
ACPI_CPU_DATA
  OvmfPkg: QuarkPort/CpuS3DataDxe: handle StackAddress and StackSize
  OvmfPkg: import CpuConfigLib header from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg
  OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.NumberOfCpus
  OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable
  OvmfPkg: QuarkPort/CpuS3DataDxe: handle register tables in
ACPI_CPU_DATA
  OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespa

[edk2] [PATCH v2 03/41] OvmfPkg: introduce -D SMM_REQUIRE and PcdSmmSmramRequire

[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 7616aa5..24747c9 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 81864eb..0ebc88b 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 fc66a13..056c0c0 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 v2 10/41] OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE

[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 f94df20..de260e4 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -671,3 +671,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 01afff9..8e82613 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -678,3 +678,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 859d074..4df7de1 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -676,3 +676,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 
b/OvmfPkg/SmmAccess/SmmAc

[edk2] [PATCH v2 24/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle StackAddress and StackSize

[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 v2 27/41] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.MtrrTable

[Laszlo Ersek]

It has been deemed inappropriate, for general use, for UefiCpuPkg/CpuDxe
to keep reflecting the most recent MTRR settings to an AcpiNVS buffer, for
CpuS3DataDxe to pass through to PiSmmCpuDxeSmm. Instead, Michael Kinney
suggested to fetch and save the MTRR settings in CpuS3DataDxe, in a
similarly delayed manner: at EndOfDxe.

That idea matches OVMF's BDS very well. The events are sequenced like
this:
- PiSmmCpuDxeSmm installs EFI_SMM_CONFIGURATION_PROTOCOL.

- SmmConfigurationEventNotify() is invoked in CpuS3DataDxe, which in turn
  calls SaveCpuS3Data().

- SaveCpuS3Data() allocates AcpiNVS memory for ACPI_CPU_DATA, and (with
  this patch) MTRR_SETTINGS too, linking the latter into the former.

- SaveCpuS3Data() registers a handler for EndOfDxe.

- Later, OVMF's BDS signals EndOfDxe, thus CpuS3DataDxe populates the
  MTRR_SETTINGS block, with the then-current MTRR settings.

- Right after, BDS writes the last opcode (an INFO opcode) to the S3 boot
  script, and installs gEfiDxeSmmReadyToLockProtocolGuid in the DXE
  protocol database.

- In turn, the SMM core installs gEfiSmmReadyToLockProtocolGuid in the SMM
  protocol database.

- In turn, SmmReadyToLockEventNotify() is called in PiSmmCpuDxeSmm, which
  copies the MTRR settings from AcpiNVS to SMRAM.

On the S3 resume path, PiSmmCpuDxeSmm will apply the MTRR settings to all
APs directly from SMRAM.

This patch significantly diverges from the original
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/ driver.

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

Notes:
v2:
- This approach is new in v2. In v1, QuarkPort/CpuS3DataDxe simply
  relayed the PcdCpuMtrrTableAddress value from UefiCpuPkg/CpuDxe to
  PiSmmCpuDxeSmm.

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  2 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 41 
 2 files changed, 43 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 249408b..2610a63 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -78,8 +78,10 @@ [LibraryClasses]
   UefiLib
   DebugLib
   BaseLib
+  MtrrLib
 
 [Guids]
+  gEfiEndOfDxeEventGroupGuid
 
 [Protocols]
   gEfiMpServiceProtocolGuid # PROTOCOL ALWAYS_CONSUMED
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
index a69c58c..25ac8b1 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
@@ -34,6 +34,8 @@
 
 **/
 
+#include 
+
 #include "MpService.h"
 #include "Cpu.h"
 #include "MpApic.h"
@@ -220,6 +222,27 @@ WakeupAPAndCollectBist (
 }
 
 /**
+  Callback function executed when the EndOfDxe event group is signaled.
+
+  We delay saving the MTRR settings until BDS signals EndOfDxe.
+
+  @param[in]  EventEvent whose notification function is being invoked.
+  @param[out] Context  Pointer to the MTRR_SETTINGS buffer to fill in.
+**/
+STATIC
+VOID
+EFIAPI
+SaveMtrrsOnEndOfDxe (
+  IN EFI_EVENT Event,
+  OUT VOID *Context
+  )
+{
+  DEBUG ((EFI_D_VERBOSE, "%a\n", __FUNCTION__));
+  MtrrGetAllMtrrs (Context);
+  gBS->CloseEvent (Event);
+}
+
+/**
   Prepare ACPI NVS memory below 4G memory for use of S3 resume.
   
   This function allocates ACPI NVS memory below 4G memory for use of S3 resume,
@@ -234,6 +257,9 @@ SaveCpuS3Data (
   )
 {
   MP_CPU_SAVED_DATA   *MpCpuSavedData;
+  MTRR_SETTINGS   *MtrrSettings;
+  EFI_STATUS  Status;
+  EFI_EVENT   EndOfDxeEvent;
 
   //
   // Allocate ACPI NVS memory below 4G memory for use of S3 resume.
@@ -241,6 +267,20 @@ SaveCpuS3Data (
   MpCpuSavedData = AllocateAcpiNvsMemoryBelow4G (sizeof (MP_CPU_SAVED_DATA));
 
   //
+  // Allocate buffer for MTRR settings.
+  //
+  MtrrSettings = AllocateAcpiNvsMemoryBelow4G (sizeof *MtrrSettings);
+
+  //
+  // Install notification callback for EndOfDxe that will fill in the MTRR
+  // settings.
+  //
+  Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_CALLBACK,
+  SaveMtrrsOnEndOfDxe, MtrrSettings,
+  &gEfiEndOfDxeEventGroupGuid, &EndOfDxeEvent);
+  ASSERT_EFI_ERROR (Status);
+
+  //
   // Set the value for CPU data
   //
   mAcpiCpuData = &(MpCpuSavedData->AcpiCpuData);
@@ -252,6 +292,7 @@ SaveCpuS3Data (
   mAcpiCpuData->StackAddress   =
 (EFI_PHYSICAL_ADDRESS) (UINTN) mExchangeInfo->StackStart;
   mAcpiCpuData->StackSize  = PcdGet32 (PcdCpuApStackSize);
+  mAcpiCpuData->MtrrTable  = (EFI_PHYSICAL_ADDRESS)(UINTN)MtrrSettings;
 
   mAcpiCpuData->ApMachineCheckHandlerBase = mApMachineCheckHandlerBase;
   mAcpiCpuData->ApMachineCheckHandlerSize = mApMachineCheckHandlerSize;
-- 
1.8.3.1


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

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

[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 of its
+contributor

[edk2] [PATCH v2 22/41] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.StartupVector

[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.)

Starting with this patch, CpuS3DataDxe grows arch-specific dependencies,
and therefore OVMF will build for Ia32 only, when -D SMM_REQUIRE is
specified.

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

Notes:
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"
 
+extern EFI_PHYSICAL_ADDRESSmStartupVector;
+
+extern ACPI_CPU_DATA

[edk2] [PATCH v2 21/41] OvmfPkg: add skeleton QuarkPort/CpuS3DataDxe

[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:
v2:
- PcdCpuS3DataAddress comes from "UefiCpuPkg/UefiCpuPkg.dec" now
- adapt the commit message to the fact that Mike added PiSmmCpuDxeSmm
  to UefiCpuPkg

 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/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 
 12 files changed, 487 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 3dc71cd..06b8608 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -707,6 +707,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 35ad8fa..dde8d39 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -714,6 +714,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 f9f4001..77e32a2 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -712,6 +712,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/CpuIo

[edk2] [PATCH v2 17/41] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

[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 10d00b9..a86b62f 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 8b02441..2227e1c 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 f2b4baf..9ab9b01 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 v2 29/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespace

[Laszlo Ersek]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 16 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c| 16 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c |  6 +++---
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 06a092d..0dcd26d 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -1,18 +1,18 @@
 /**@file
 
 Copyright (c) 2006, 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.  
   
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 Module Name:
 
   FwBlockService.h
-  
+
 Abstract:
 
   Firmware volume block driver for Intel Firmware Hub (FWH) device
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
index 62f9158..4eb6961 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
@@ -1,13 +1,13 @@
 /**@file
 
 Copyright (c) 2006, 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.  
   
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
 Module Name:
 
@@ -75,7 +75,7 @@ EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
   FixedPcdGet32 (PcdOvmfFlashNvStorageEventLogSize),
   EFI_FVH_SIGNATURE,
-  EFI_FVB2_MEMORY_MAPPED |  
+  EFI_FVB2_MEMORY_MAPPED |
 EFI_FVB2_READ_ENABLED_CAP |
 EFI_FVB2_READ_STATUS |
 EFI_FVB2_WRITE_ENABLED_CAP |
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 9160bb8..075fac3 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -871,7 +871,7 @@ Returns:
   ) {
 return EFI_NOT_FOUND;
   }
-  
+
   //
   // Verify the header checksum
   //
@@ -944,7 +944,7 @@ InitializeVariableFvHeader (
 (EFI_FIRMWARE_VOLUME_HEADER *) (UINTN)
   PcdGet32 (PcdOvmfFlashNvStorageVariableBase);
 
-  Length = 
+  Length =
 (FixedPcdGet32 (PcdFlashNvStorageVariableSize) +
  FixedPcdGet32 (PcdFlashNvStorageFtwWorkingSize) +
  FixedPcdGet32 (PcdFlashNvStorageFtwSpareSize) +
@@ -1139,7 +1139,7 @@ Returns:
   } else {
 FvbDevice->DevicePath = (EFI_DEVICE_PATH_PROTOCOL *) AllocateCopyPool 
(sizeof (FV_PIWG_DEVICE_PATH), &mFvPIWGDevicePathTemplate);
 CopyGuid (
-  &((FV_PIWG_DEVICE_PATH *)FvbDevice->DevicePath)->FvDevPath.FvName, 
+  &((FV_PIWG_DEVICE_PATH *)FvbDevice->DevicePath)->FvDevPath.FvName,
   (GUID *)(UINTN)(BaseAddress + FwVolHeader->ExtHeaderOffset)
   );
   }
-- 
1.8.3.1


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

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

[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 da6967f..40f1d26 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   0x0004000

[edk2] [PATCH v2 28/41] OvmfPkg: QuarkPort/CpuS3DataDxe: handle register tables in ACPI_CPU_DATA

[Laszlo Ersek]

Each one of the "PreSmmInitRegisterTable" and "RegisterTable" fields in
ACPI_CPU_DATA is a pointer to an array of CPU_REGISTER_TABLE objects; one
object per logical processor. Each table carries a variable number of
CPU_REGISTER_TABLE_ENTRY objects; each entry prescribes a specific
register setting for the CPU whose CPU_REGISTER_TABLE the entry is in.

Such entries are added to the tables with the following CpuConfigLib
functions:
- WriteRegisterTableEx(): internal helper,
- WriteRegisterTable(): public function for RegisterTable,
- WritePreSmmInitRegisterTable(): public function for
  PreSmmInitRegisterTable.

* The driver

Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

  allocates the array of CPU_REGISTER_TABLEs in AcpiNVS for
  ACPI_CPU_DATA.PreSmmInitRegisterTable, and sets the InitialApicID field
  of each table object. (This is then later used by PiSmmCpuDxeSmm to
  match a table against a logical CPU.)

  However, CpuMpDxe never actually adds any register entries to any
  processor's table in the PreSmmInitRegisterTable, either with
  WritePreSmmInitRegisterTable(), or manually.

* CpuMpDxe is theoretically capable of adding register entries (MSR, CRn
  changes etc) to the elements of the array pointed-to by
  ACPI_CPU_DATA.RegisterTable. See the following call tree in CpuMpDxe:

  ProduceRegisterTable()
MaxCpuidLimitReg()
  WriteRegisterTable(
..., MSR_IA32_MISC_ENABLE, N_MSR_LIMIT_CPUID_MAXVAL, ...
)
XdReg()
  WriteRegisterTable(
..., MSR_IA32_MISC_ENABLE, N_MSR_XD_BIT_DISABLE, ...
)

  However, both MaxCpuidLimitReg() and XdReg() are gated by feature PCDs;
  we'll just consider those disabled.

Therefore, we'll explicitly instruct PiSmmCpuDxeSmm to do nothing in
response to these tables: we allocate both arrays, but leave them
zero-filled.

That will short-circuit the processing in PiSmmCpuDxeSmm for most logical
CPUs, in the

  (RegisterTableList[Index].InitialApicId == InitApicId)

checks. And when those checks don't fail, and SetProcessorRegister() gets
called, then the

  RegisterTable->TableLength == 0

equality will short-circuit that function.

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

Notes:
v2:
- This patch replaces the following v1 patches:
  - OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.PreSmmInitRegisterTable
  - OvmfPkg: QuarkPort: drop ACPI_CPU_DATA.RegisterTable
  It intends to have the same effect, but without modifying the
  ACPI_CPU_DATA structure, or PiSmmCpuDxeSmm.

 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
index 25ac8b1..1f4a081 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c
@@ -57,6 +57,9 @@ PrepareMemoryForConfiguration (
   VOID
   )
 {
+  UINTNNumberOfProcessors;
+  UINTNRegisterTableSize;
+
   //
   // Claim memory for AP stack.
   //
@@ -64,6 +67,17 @@ PrepareMemoryForConfiguration (
 PcdGet32 (PcdCpuMaxLogicalProcessorNumber) *
 PcdGet32 (PcdCpuApStackSize)
 );
+
+  //
+  // OVMF port note: leaving these tables zero-filled tells PiSmmCpuDxeSmm that
+  // there is no work to do.
+  //
+  NumberOfProcessors = mCpuConfigConextBuffer.NumberOfProcessors;
+  RegisterTableSize = sizeof (CPU_REGISTER_TABLE) * NumberOfProcessors;
+  mCpuConfigConextBuffer.RegisterTable =
+AllocateAcpiNvsMemoryBelow4G (RegisterTableSize);
+  mCpuConfigConextBuffer.PreSmmInitRegisterTable =
+AllocateAcpiNvsMemoryBelow4G (RegisterTableSize);
 }
 
 /**
@@ -294,6 +308,12 @@ SaveCpuS3Data (
   mAcpiCpuData->StackSize  = PcdGet32 (PcdCpuApStackSize);
   mAcpiCpuData->MtrrTable  = (EFI_PHYSICAL_ADDRESS)(UINTN)MtrrSettings;
 
+  mAcpiCpuData->RegisterTable =
+(EFI_PHYSICAL_ADDRESS)(UINTN)mCpuConfigConextBuffer.RegisterTable;
+  mAcpiCpuData->PreSmmInitRegisterTable =
+(EFI_PHYSICAL_ADDRESS)(UINTN)
+  mCpuConfigConextBuffer.PreSmmInitRegisterTable;
+
   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 v2 26/41] OvmfPkg: QuarkPort/CpuS3DataDxe: fill in ACPI_CPU_DATA.NumberOfCpus

[Laszlo Ersek]

Following the same method as before, we incorporate code from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe that sets
"mCpuConfigConextBuffer.NumberOfProcessors" on the entry point's call
stack, and ultimately stores it into ACPI_CPU_DATA.NumberOfCpus on
SmmConfigurationEventNotify()'s call stack.

The CheckApicId() function is scavenged from
Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe because it contains
useful checks, and the SortApicId() function is taken (and completely
rewritten) because that's the one that sets
"mCpuConfigConextBuffer.NumberOfProcessors".

Unlike in Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe, which
implements the CPU MP Services itself, in SortApicId() we retrieve the
number of processors from the same protocol provided by UefiCpuPkg/CpuDxe.

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

Notes:
v2:
- in v2, this is the patch where CpuS3DataDxe starts depending on
  OvmfPkg/OvmfPkg.dec

 OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf  |  6 +-
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpApic.h  | 69 +++
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpCommon.h|  3 +
 OvmfPkg/QuarkPort/CpuS3DataDxe/MpApic.c  | 93 
 OvmfPkg/QuarkPort/CpuS3DataDxe/ProcessorConfig.c | 21 +
 5 files changed, 191 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
index 4ade193..249408b 100644
--- a/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/CpuS3DataDxe.inf
@@ -54,6 +54,8 @@ [Sources]
   MpCommon.h
   MpCommon.c
   Cpu.h
+  MpApic.c
+  MpApic.h
 
 [Sources.Ia32]
   IA32/CpuAsm.asm
@@ -66,6 +68,7 @@ [Packages]
   IntelFrameworkPkg/IntelFrameworkPkg.dec
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   UefiCpuPkg/UefiCpuPkg.dec
+  OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
   UefiBootServicesTableLib
@@ -79,6 +82,7 @@ [LibraryClasses]
 [Guids]
 
 [Protocols]
+  gEfiMpServiceProtocolGuid # PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyBiosProtocolGuid## SOMETIMES_CONSUMES
   gEfiSmmConfigurationProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
 
@@ -93,4 +97,4 @@ [Pcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEbdaReservedMemorySize
 
 [Depex]
-  TRUE
+  gEfiMpServiceProtocolGuid
diff --git a/OvmfPkg/QuarkPort/CpuS3DataDxe/MpApic.h 
b/OvmfPkg/QuarkPort/CpuS3DataDxe/MpApic.h
new file mode 100644
index 000..7a6e93d
--- /dev/null
+++ b/OvmfPkg/QuarkPort/CpuS3DataDxe/MpApic.h
@@ -0,0 +1,69 @@
+/** @file
+
+  Include file for APIC feature.
+
+  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:  MpApic.h
+
+**/
+
+#ifndef _CPU_MP_APIC_H_
+#define _CPU_MP_APIC_H_
+
+#include "Cpu.h"
+
+/**
+  Sort the APIC ID of all processors.
+
+  This function sorts the APIC ID of all processors so that processor number is
+  assigned in the ascending order of APIC ID which eases MP debugging. SMBIOS
+  logic also depends on this assumption.
+
+**/
+VOID
+SortApicId (
+  VOID
+  );
+
+/**
+  Check if there is legacy APIC ID conflict among all processors.
+
+  @retval EFI_SUCCESS  No coflict or conflict was resoved by force x2APIC
+   mode
+  @retval EFI_UNSUPPORTED  There is legacy APIC ID conflict and can't be
+   rsolved in xAPIC mode
+**/
+EFI_STATUS
+CheckApicId (
+  VOID
+  );
+
+#e

[edk2] [PATCH v2 32/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbDevLock field

[Laszlo Ersek]

The EFI_FW_VOL_INSTANCE.FvbDevLock member is initialized and then never
used. Remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 6fa7c7e..67140d0 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -30,7 +30,6 @@
 #define FVB_VIRTUAL   1
 
 typedef struct {
-  EFI_LOCKFvbDevLock;
   UINTN   FvBase[2];
   UINTN   NumOfBlocks;
   EFI_FIRMWARE_VOLUME_HEADER  VolumeHeader;
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index c542482..3e7fe68 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -1119,7 +1119,6 @@ FvbInitialize (
   CopyMem ((UINTN *) &(FwhInstance->VolumeHeader), (UINTN *) FwVolHeader,
 FwVolHeader->HeaderLength);
   FwVolHeader = &(FwhInstance->VolumeHeader);
-  EfiInitializeLock (&(FwhInstance->FvbDevLock), TPL_HIGH_LEVEL);
 
   NumOfBlocks = 0;
 
-- 
1.8.3.1


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

[edk2] [PATCH v2 30/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: rewrap source code to 79 chars

[Laszlo Ersek]

Some of the line lengths in this driver are atrocious. While we have to
put up with the status quo outside of OvmfPkg, we can at least rewrap this
driver before refactoring it.

In the FvbInitialize() function there's no way around introducing two
local variables, just for the sake of sensibly rewrapping the code.

Furthermore, in "FwBlockService.c" the function comment blocks are now
indented; their original position causes diff to print bogus function
names at the top of hunks.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf |  25 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h  |  31 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h   |   7 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c |  36 +-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  | 513 
+++-
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |   7 +-
 6 files changed, 337 insertions(+), 282 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index e3e7176..ac903b5 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -1,17 +1,20 @@
 ## @file
-# Component description file for QEMU Flash Fimware Volume Block DXE driver 
module.
+#  Component description file for QEMU Flash Fimware Volume Block DXE driver
+#  module.
 #
-# This DXE runtime driver implements and produces the Fimware Volue Block 
Protocol
-# for a QEMU flash device.
+#  This DXE runtime driver implements and produces the Fimware Volue Block
+#  Protocol for a QEMU flash device.
 #
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
+#  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
+#  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.
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
 #
 ##
 
@@ -24,7 +27,8 @@ [Defines]
   ENTRY_POINT= FvbInitialize
 
 #
-# The following information is for reference only and not required by the 
build tools.
+# The following information is for reference only and not required by the build
+# tools.
 #
 #  VALID_ARCHITECTURES   = IA32
 #
@@ -53,7 +57,8 @@ [LibraryClasses]
   PcdLib
 
 [Guids]
-  gEfiEventVirtualAddressChangeGuid # ALWAYS_CONSUMED  Create 
Event: EVENT_GROUP_GUID
+  gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
+  # gEfiEventVirtualAddressChangeGuid # Create Event: EVENT_GROUP_GUID
 
 [Protocols]
   gEfiFirmwareVolumeBlockProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 0dcd26d..6fa7c7e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -1,21 +1,22 @@
 /**@file
 
-Copyright (c) 2006, 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
+  Copyright (c) 2006, Intel Corporation. All rights reserved.
 
-THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+  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
 
-Module Name:
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-  FwBlockService.h
+  Module Name:
 
-Abstract:
+FwBlockService.h
 
-  Firmware volume block driver for Intel Firmware Hub (FWH) device
+  Abstract:
+
+Firmware volume block driver for Intel Firmware Hub (FWH) device
 
 **/
 
@@ -44,8 +45,12 @@ typedef struct {
 //

[edk2] [PATCH v2 31/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix VALID_ARCHITECTURES in INF

[Laszlo Ersek]

We build this driver for X64 as well -- the comment isn't overly
important, but it shouldn't be misleading.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index ac903b5..5f0264b 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -30,7 +30,7 @@ [Defines]
 # The following information is for reference only and not required by the build
 # tools.
 #
-#  VALID_ARCHITECTURES   = IA32
+#  VALID_ARCHITECTURES   = IA32 X64
 #
 
 [Sources]
-- 
1.8.3.1


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

[edk2] [PATCH v2 33/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: remove FvbScratchSpace field

[Laszlo Ersek]

The ESAL_FWB_GLOBAL.FvbScratchSpace array is never initialized (it
contains garbage from AllocateRuntimePool()). Its element at subscript one
(=FVB_VIRTUAL), containing garbage as well, is converted to virtual
mapping. Then the array is never used again.

Remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 1 -
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 67140d0..7e4ff1e 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -38,7 +38,6 @@ typedef struct {
 typedef struct {
   UINT32  NumFv;
   EFI_FW_VOL_INSTANCE *FvInstance[2];
-  UINT8   *FvbScratchSpace[2];
 } ESAL_FWB_GLOBAL;
 
 //
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 3e7fe68..95ae8cc 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -169,8 +169,6 @@ FvbVirtualddressChangeEvent (
 Index++;
   }
 
-  EfiConvertPointer (0x0,
-(VOID **) &mFvbModuleGlobal->FvbScratchSpace[FVB_VIRTUAL]);
   EfiConvertPointer (0x0, (VOID **) &mFvbModuleGlobal);
   QemuFlashConvertPointers ();
 }
-- 
1.8.3.1


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

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

[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 
---
 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 v2 34/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: no dual addressing needed

[Laszlo Ersek]

Currently the EFI_FW_VOL_INSTANCE and ESAL_FWB_GLOBAL structures declare
the following entries as arrays, with two entries each:

- EFI_FW_VOL_INSTANCE.FvBase[2]
- ESAL_FWB_GLOBAL.FvInstance[2]

In every case, the entry at subscript zero is meant as "physical address",
while the entry at subscript one is meant as "virtual address" -- a
pointer to the same object. The virtual address entry is originally
initialized to the physical address, and then it is converted to the
virtual mapping in FvbVirtualddressChangeEvent().

Functions that (a) read the listed fields and (b) run both before and
after the virtual address change event -- since this is a runtime DXE
driver -- derive the correct array subscript by calling the
EfiGoneVirtual() function from UefiRuntimeLib.

The problem with the above infrastructure is that it's entirely
superfluous.

EfiGoneVirtual() "knows" whether EFI has gone virtual only because the
UefiRuntimeLib constructor registers the exact same kind of virtual
address change callback, and the callback flips a static variabe to TRUE,
and EfiGoneVirtual() queries that static variable.

In effect this means for QemuFlashFvbServicesRuntimeDxe: "when there is a
virtual address change, convert the entries with subscript one from
physical to virtual, and from then on use the entries with subscript one".

This would only make sense if QemuFlashFvbServicesRuntimeDxe ever needed
the original (physical) addresses (ie. the entries with subscript zero)
after the virtual address change, but that is not the case.

Replace the arrays with single elements. The subscript zero elements
simply disappear, and the single elements take the role of the prior
subscript one elements.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h | 22 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c | 77 
++--
 2 files changed, 30 insertions(+), 69 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 7e4ff1e..5e8c2c7 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -23,21 +23,15 @@
 #ifndef _FW_BLOCK_SERVICE_H
 #define _FW_BLOCK_SERVICE_H
 
-//
-// BugBug: Add documentation here for data structure
-//
-#define FVB_PHYSICAL  0
-#define FVB_VIRTUAL   1
-
 typedef struct {
-  UINTN   FvBase[2];
+  UINTN   FvBase;
   UINTN   NumOfBlocks;
   EFI_FIRMWARE_VOLUME_HEADER  VolumeHeader;
 } EFI_FW_VOL_INSTANCE;
 
 typedef struct {
   UINT32  NumFv;
-  EFI_FW_VOL_INSTANCE *FvInstance[2];
+  EFI_FW_VOL_INSTANCE *FvInstance;
 } ESAL_FWB_GLOBAL;
 
 //
@@ -78,24 +72,21 @@ EFI_STATUS
 FvbSetVolumeAttributes (
   IN UINTNInstance,
   IN OUT EFI_FVB_ATTRIBUTES_2 *Attributes,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
 FvbGetVolumeAttributes (
   IN UINTNInstance,
   OUT EFI_FVB_ATTRIBUTES_2*Attributes,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
 FvbGetPhysicalAddress (
   IN UINTNInstance,
   OUT EFI_PHYSICAL_ADDRESS*Address,
-  IN ESAL_FWB_GLOBAL  *Global,
-  IN BOOLEAN  Virtual
+  IN ESAL_FWB_GLOBAL  *Global
   );
 
 EFI_STATUS
@@ -120,8 +111,7 @@ FvbGetLbaAddress (
   OUT UINTN   *LbaAddress,
   OUT UINTN   *LbaLength,
   OUT UINTN   *NumOfBlocks,
-  IN  ESAL_FWB_GLOBAL *Global,
-  IN  BOOLEAN Virtual
+  IN  ESAL_FWB_GLOBAL *Global
   );
 
 //
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 95ae8cc..3eccb1f 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -132,11 +132,6 @@ FvbVirtualddressChangeEvent (
 Call the passed in Child Notify event and convert the mFvbModuleGlobal
 date items to there virtual address.
 
-mFvbModuleGlobal->FvInstance[FVB_PHYSICAL]  - Physical copy of instance
-  data
-mFvbModuleGlobal->FvInstance[FVB_VIRTUAL]   - Virtual pointer to common
-  instance data.
-
   Arguments:
 
 (Standard EFI notify event - EFI_EVENT_NOTIFY)
@@ -150,16 +145,15 @@ FvbVirtua

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

[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 
---

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 f10942f..7e54578 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -309,6 +309,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -723,10 +724,22 @@ [Components]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   
SmmCpuFeaturesLib|UefiCpuPkg/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 {
@@ -738,3 +751,4 @@ [Components]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 329e668..7ce97c0 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -314,6 +314,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -730,10 +731,22 @@ [Components.X64]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   
SmmCpuFeaturesLib|UefiCpuPkg/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 {
@@ -745,3 +758,4 @@ [Components.X64]
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
   }
+!endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a10e0eb..0c2ecee 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -314,6 +314,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
 
 [LibraryClasses.common.SMM_CORE]
   PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
@@ -728,10 +729,22 @@ [Components]
   SmmLib|MdePkg/Library/SmmLibNull/SmmLibNull.inf
   
SmmCpuFeaturesLib|UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
   }
-!endif
 
   #
-  # Variable driver stack
+  # Variable driver stack (SMM)
+  #
+  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
+  MdeModulePkg/Universal

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

[Laszlo Ersek]

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

Notes:
v2:
- documented "-nx" VCPU feature flag
  

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

diff --git a/OvmfPkg/README b/OvmfPkg/README
index 147e6e0..49aaae4 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -118,6 +118,49 @@ $ 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 following flags (in addition to any other
+flags):
+
+  qemu-system-i386 \
+-machine q35,smm=on,accel=(tcg|kvm) \
+-global driver=cfi.pflash01,property=secure,value=on \
+-smp cpus=1 \
+-cpu coreduo,-nx \
+...
+
+OVMF's SMM support is subject to the following by-design limitations:
+- only the q35 machine type of QEMU is supported,
+- for 32-bit VCPUs ("qemu-system-i386" and "qemu-system-x86_64 -cpu
+  ,-lm"), the NX processor feature flag has to be disabled ("-cpu
+  ,...,-nx").
+
+OVMF's SMM support is subject to the following shortcomings:
+- it works only in uniprocessor guests,
+- with TCG acceleration, it works only on qemu-system-i386 (not on
+  qemu-system-x86_64),
+- with KVM acceleration, it should work on qemu-system-x86_64 in addition to
+  qemu-system-i386, but a 32-bit VCPU is required nonetheless (that is, long
+  mode must be disabled with the "-cpu ,-lm" switch).
+
+These issues will hopefully be addressed in the future.
+
 === 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 v2 35/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: split out runtime DXE specifics

[Laszlo Ersek]

In preparation for introducing an SMM interface to this driver, move the
following traits to separate files, so that we can replace them in the new
SMM INF file:

- Protocol installations. The SMM driver will install protocol interfaces
  in the SMM protocol database, using SMM services.

- Virtual address change handler and pointer conversions. SMM drivers run
  with physical mappings and pointers must not be converted.

There are further restrictions and changes for an SMM driver, but the rest
of the code either complies with those already, or will handle the changes
transparently. For example:

- SMM drivers have access to both UEFI and SMM protocols in their entry
  points (see the PI spec 1.4, "1.7 SMM Driver Initialization"),

- MemoryAllocationLib has an SMM instance that serves allocation requests
  with the gSmst->SmmAllocatePool() service transparently, allocating
  runtime-marked SMRAM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf |   2 +
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h  |  15 ++
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h   |   2 +
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  | 122 
+---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockServiceDxe.c   | 154 

 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |  17 +--
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c|  28 
 7 files changed, 209 insertions(+), 131 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index 5f0264b..480b694 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -36,7 +36,9 @@ [Defines]
 [Sources]
   FvbInfo.c
   FwBlockService.c
+  FwBlockServiceDxe.c
   QemuFlash.c
+  QemuFlashDxe.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
index 5e8c2c7..1f9287b 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.h
@@ -34,6 +34,8 @@ typedef struct {
   EFI_FW_VOL_INSTANCE *FvInstance;
 } ESAL_FWB_GLOBAL;
 
+extern ESAL_FWB_GLOBAL *mFvbModuleGlobal;
+
 //
 // Fvb Protocol instance data
 //
@@ -174,4 +176,17 @@ FvbProtocolEraseBlocks (
   ...
   );
 
+//
+// The following functions have different implementations dependent on the
+// module type chosen for building this driver.
+//
+VOID
+InstallProtocolInterfaces (
+  IN EFI_FW_VOL_BLOCK_DEVICE *FvbDevice
+  );
+
+VOID
+InstallVirtualAddressChangeHandler (
+  VOID
+  );
 #endif
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
index 975010e..8d83dca 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
@@ -18,6 +18,8 @@
 
 #include 
 
+extern UINT8 *mFlashBase;
+
 /**
   Read from QEMU Flash
 
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 3eccb1f..0158bf9 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -21,25 +21,16 @@
 **/
 
 //
-// The package level header files this module uses
-//
-#include 
-
-//
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
 #include 
 #include 
 
 //
 // The Library classes this module consumes
 //
-#include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -117,56 +108,6 @@ EFI_FW_VOL_BLOCK_DEVICE mFvbDeviceTemplate = {
 };
 
 
-
-VOID
-EFIAPI
-FvbVirtualddressChangeEvent (
-  IN EFI_EVENTEvent,
-  IN VOID *Context
-  )
-/*++
-
-  Routine Description:
-
-Fixup internal data so that EFI and SAL can be call in virtual mode.
-Call the passed in Child Notify event and convert the mFvbModuleGlobal
-date items to there virtual address.
-
-  Arguments:
-
-(Standard EFI notify event - EFI_EVENT_NOTIFY)
-
-  Returns:
-
-None
-
---*/
-{
-  EFI_FW_VOL_INSTANCE *FwhInstance;
-  UINTN   Index;
-
-  FwhInstance = mFvbModuleGlobal->FvInstance;
-  EfiConvertPointer (0x0, (VOID **) &mFvbModuleGlobal->FvInstance);
-
-  //
-  // Convert the base address of all the instances
-  //
-  Index   = 0;
-  while (Index < mFvbModuleGlobal->NumFv) {
-EfiConvertPointer (0x0, (VOID **) &FwhInstance->FvBase);
-FwhInstance = (EFI_FW_VOL_INSTANCE *)
-  (
-(UINTN) ((UINT8 *) FwhInstance) +
-FwhInstance->VolumeHeader.HeaderLength +
-(sizeof (EFI_FW_VOL_INSTANCE) - sizeof (EFI_FIRMWARE_VOLUME_HEAD

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

[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 
---
 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 06b8608..f10942f 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -533,19 +533,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
@@ -734,3 +724,17 @@ [Components]
   
SmmCpuFeaturesLib|UefiCpuPkg/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 dde8d39..329e668 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -540,19 +540,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
@@ -741,3 +731,17 @@ [Components.X64]
   
SmmCpuFeaturesLib|UefiCpuPkg/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 77e32a2..a10e0eb 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -538,19 +538,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/Librar

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

[Laszlo Ersek]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 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 SMM FVB\n"));
+  Status = gSmst->SmmInstallProtocolInterface (
+   

[edk2] [PATCH v2 36/41] OvmfPkg: QemuFlashFvbServicesRuntimeDxe: clean up includes and libraries

[Laszlo Ersek]

Before introducing the SMM driver interface, clean up #include directives
and [LibraryClasses] by:
- removing what's not directly used,
- adding what's used but not spelled out,
- sorting the result.

This helps with seeing each source file's dependencies and with
determining the library classes for the SMM driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf | 13 
++---
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c | 16 
++--
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c  |  8 
 OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c   |  2 +-
 4 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
index 480b694..ea8413f 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
@@ -46,17 +46,16 @@ [Packages]
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
-  UefiBootServicesTableLib
-  MemoryAllocationLib
+  BaseLib
   BaseMemoryLib
-  HobLib
   DebugLib
-  UefiRuntimeLib
+  DevicePathLib
   DxeServicesTableLib
-  BaseLib
-  UefiDriverEntryPoint
-  UefiLib
+  MemoryAllocationLib
   PcdLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  UefiRuntimeLib
 
 [Guids]
   gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
index ec6bfdb..6edbeed 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbInfo.c
@@ -24,28 +24,16 @@
 //
 // The package level header files this module uses
 //
-#include 
+#include 
+
 //
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
-#include 
 #include 
-#include 
-#include 
 //
 // The Library classes this module consumes
 //
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
 typedef struct {
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
index 0158bf9..c37aed1 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FwBlockService.c
@@ -23,19 +23,19 @@
 //
 // The protocols, PPI and GUID defintions for this module
 //
-#include 
 #include 
+#include 
 
 //
 // The Library classes this module consumes
 //
 #include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
 
 #include "FwBlockService.h"
 #include "QemuFlash.h"
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
index 5b03046..28bcb13 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
@@ -13,8 +13,8 @@
 
 **/
 
-#include 
 #include 
+#include 
 #include 
 
 #include "QemuFlash.h"
-- 
1.8.3.1


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

Re: [edk2] [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

[Fan, Jeff]

Reviewed-by: Jeff Fan 

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Saturday, October 10, 2015 5:58 AM
To: edk2-de...@ml01.01.org
Cc: Fan, Jeff; Chen Fan; Justen, Jordan L; Kinney, Michael D
Subject: [PATCH v2 02/41] UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs

The

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuArchDxe

driver applies any MTRR changes to APs, if the EFI_MP_SERVICES_PROTOCOL is 
available. We should do the same.

Additionally, the broadcast should occur at MP startup as well, not only when 
MTRR settings are changed. The inspiration is taken from

  Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/CpuMpDxe/

(see the EarlyMpInit() function and its call sites in "ProcessorConfig.c").

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

Notes:
v2:
- This patch replaces the following patches from v1:
  - UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory
block
  - UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs
  - UefiCpuPkg: CpuDxe: sync MTRR settings to APs at MP startup
  - UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL when there's no
AP

  The first v1 patch was deemed inappropriate for general use, and Mike
  suggested a good alternative for OVMF (=> grab MTRR settings in
  CpuS3DataDxe at EndOfDxe).

  The second and third v1 patches are now squashed together into this v2
  patch; they are small and belong together logically.

  The fourth v1 patch is redundant now; the same has been covered by
  Mike.

 UefiCpuPkg/CpuDxe/CpuMp.h  | 13   UefiCpuPkg/CpuDxe/CpuDxe.c | 26 
+++  UefiCpuPkg/CpuDxe/CpuMp.c  | 34 +++-
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/CpuDxe/CpuMp.h b/UefiCpuPkg/CpuDxe/CpuMp.h index 
d2866e4..503f3ae 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.h
+++ b/UefiCpuPkg/CpuDxe/CpuMp.h
@@ -643,5 +643,18 @@ ResetApStackless (
   IN UINT32 ProcessorId
   );
 
+/**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed 
+to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  );
+
 #endif // _CPU_MP_H_
 
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c index 
c9df4e1..daf97bd 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -350,6 +350,9 @@ CpuSetMemoryAttributes (  {
   RETURN_STATUS Status;
   MTRR_MEMORY_CACHE_TYPECacheType;
+  EFI_STATUSMpStatus;
+  EFI_MP_SERVICES_PROTOCOL  *MpService;
+  MTRR_SETTINGS MtrrSettings;
 
   if (!IsMtrrSupported ()) {
 return EFI_UNSUPPORTED;
@@ -405,6 +408,29 @@ CpuSetMemoryAttributes (
  CacheType
  );
 
+  if (!RETURN_ERROR (Status)) {
+MpStatus = gBS->LocateProtocol (
+  &gEfiMpServiceProtocolGuid,
+  NULL,
+  (VOID **)&MpService
+  );
+//
+// Synchronize the update with all APs
+//
+if (!EFI_ERROR (MpStatus)) {
+  MtrrGetAllMtrrs (&MtrrSettings);
+  MpStatus = MpService->StartupAllAPs (
+  MpService,  // This
+  SetMtrrsFromBuffer, // Procedure
+  TRUE,   // SingleThread
+  NULL,   // WaitEvent
+  0,  // TimeoutInMicrosecsond
+  &MtrrSettings,  // ProcedureArgument
+  NULL// FailedCpuList
+  );
+  ASSERT (MpStatus == EFI_SUCCESS || MpStatus == EFI_NOT_STARTED);
+}
+  }
   return (EFI_STATUS) Status;
 }
 
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c index 
da3686e..fbe43f5 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -1626,6 +1626,22 @@ ExitBootServicesCallback (  }
 
 /**
+  A minimal wrapper function that allows MtrrSetAllMtrrs() to be passed 
+ to
+  EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() as Procedure.
+
+  @param[in] Buffer  Pointer to an MTRR_SETTINGS object, to be passed to
+ MtrrSetAllMtrrs().
+**/
+VOID
+EFIAPI
+SetMtrrsFromBuffer (
+  IN VOID *Buffer
+  )
+{
+  MtrrSetAllMtrrs (Buffer);
+}
+
+/**
   Initialize Multi-processor support.
 
 **/
@@ -1634,7 +1650,8 @@ InitializeMpSupport (
   VOID
   )
 {
-  EFI_STATUS Status;
+  EFI_STATUSStatus;
+  MTRR_SETTINGS MtrrSettings;
 
   gMaxLogicalProcessorNumber = (UINTN) PcdGet32 
(PcdCpuMaxLogicalProcessorNumber);
   if (gMaxLogicalProcessorNumber < 1) { @@ -1690,6 +1707,21 @@ 
InitializeMpSupport (

[edk2] [BaseTool][UPT][patch]Fix two wrong import for UPT

[Chen, Hesheng]

Hello Liming and all,
Could you help review this patch? Thank you

[Description]
1.  Fix two wrong import for UPT

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 


Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com

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

Re: [edk2] [BaseTool][UPT][patch]Fix two wrong import for UPT

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Chen, Hesheng 
Sent: Saturday, October 10, 2015 1:43 PM
To: Gao, Liming; edk2-devel@lists.01.org
Subject: [BaseTool][UPT][patch]Fix two wrong import for UPT

Hello Liming and all,
Could you help review this patch? Thank you

[Description]
1.  Fix two wrong import for UPT

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 


Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com

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