Re: [edk2] Sync notes review for Grantley

[Fan, Jeff]

Sorry, the last mail is sent wrongly to this mail list. Please ignore it. Sorry 
for this disturb.

Jeff
From: Fan, Jeff [mailto:jeff@intel.com]
Sent: Tuesday, December 10, 2013 2:23 PM
To: Wu, Mike; Tian, Hot
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] Sync notes review for Grantley

Hi, all

Please help to review the Grantley Sync notes. Thanks!

Jeff
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] uUEFI code execution

[Parmeshwr_Prasad]

Thanks Andrew/Tim, for quick reply.

From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, December 10, 2013 6:51 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] uUEFI code execution


On Dec 8, 2013, at 8:05 PM, 
parmeshwr_pra...@dell.com wrote:


Hi All,

How to get UEFI scheduling information ?

There is not a scheduler, there is just an event queue.

If you look in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Event/Timer.c,
 CoreTimerTick() is called on the timer tick. You can see it get registered in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c

The event queues are generally processed on gBS->RestoreTpl(). See 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c


/**

  Lowers the task priority to the previous value.   If the new

  priority unmasks events at a higher priority, they are dispatched.



  @param  NewTpl  New, lower, task priority



**/

VOID

EFIAPI

CoreRestoreTpl (

  IN EFI_TPL NewTpl

  )

{

  EFI_TPL OldTpl;



  OldTpl = gEfiCurrentTpl;

  ASSERT (NewTpl <= OldTpl);

  ASSERT (VALID_TPL (NewTpl));



  //

  // If lowering below HIGH_LEVEL, make sure

  // interrupts are enabled

  //



  if (OldTpl >= TPL_HIGH_LEVEL  &&  NewTpl < TPL_HIGH_LEVEL) {

gEfiCurrentTpl = TPL_HIGH_LEVEL;

  }



  //

  // Dispatch any pending events

  //

  while (((-2 << NewTpl) & gEventPending) != 0) {

gEfiCurrentTpl = (UINTN) HighBitSet64 (gEventPending);

if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {

  CoreSetInterruptState (TRUE);

}

CoreDispatchEventNotifies (gEfiCurrentTpl);

  }



  //

  // Set the new value

  //



  gEfiCurrentTpl = NewTpl;



  //

  // If lowering below HIGH_LEVEL, make sure

  // interrupts are enabled

  //

  if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {

CoreSetInterruptState (TRUE);

  }



}



Is this single or multi-threaded environment ?

EFI is really an event model. I've found this presentation to be helpful in 
explaining the difference between a thread model and an event model: 
http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf


Thanks,

Andrew Fish
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Sync notes review for Grantley

[Fan, Jeff]

Hi, all

Please help to review the Grantley Sync notes. Thanks!

Jeff
This file lists all changes need to applied when sync the latest Grantley tip.

Changes for BP 1.0.1.3

[SVN] BP r63703 - in trunk/BP/BP1.1/GrantleyPkg
  MdeModulePkg/Universal/SetupBrowerDxe is updated.
  i)  Please add the following library instance in platform DSC file.
  [LibraryClasses.common]
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib
/CustomizedDisplayLib.inf
  ii) Please add the following module in platform DSC and FDF file, it will
  co-work with SetupBrowerDxe driver.
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf

[SVN] BP r64057 - in trunk/BP/BP1.1/GrantleyPkg/Cpu/Dxe
  Ia32FamilyCpuPkg/CpuMpDxe/CpuMpDxe.inf is updated to depend on new protocol
  gIntelCpuPcdsSetDoneProtocolGuid. Please update one platform DXE driver to
  install this protocol after CPU related dynamic PCDs are set.



Changes for BP 1.1.0.0 candidate

[SVN] BP r63599 - in trunk/BP/BP1.1/GrantleyPkg
  1. CPU Exception Handler Library is added, please add its instances in
 platform DSC file accordingly.
  2. Add MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
 in platform DSC/FDF files.
  3. Rename EFI_DRIVER_HEALTH_REPAIR_PROGRESS_NOTIFY to
 EFI_DRIVER_HEALTH_REPAIR_NOTIFY.
  4. Replace gEfiGlobalVariableGuid with gServerCommonTokenSpaceGuid for
 variable L"BootState".

[SVN] BP r63691 - in trunk/BP/BP1.1/ServerCommonPkg GrantleyPkg
[SVN] BP r63703 - in trunk/BP/BP1.1/GrantleyPkg/Me/AMT/Platform/Dxe/AmtPetAlert
  Variables drivers are updated to check gEfiGlobalVariableGuid mis-used issue.
  Please update drivers to replace gEfiGlobalVariableGuid with another GUID 
when 
  reading/writing one private variable.

[SVN] BP r63784 - trunk/BP/BP1.1/WellsburgPkg/Reset/RuntimeDxe
  EFI_SPECIFICATION_VERSION is updated to EFI_2_40_SYSTEM_TABLE_REVISION. Please
  check if platform driver has assumption on EFI_SPECIFICATION_VERSION value.

[SVN] BP r64015 - in trunk/BP/BP1.1GrantleyPkg/Library/PlatformBootManagerLib
  Move the "Timeout" and "BootOptionSupport" modification from BDS core to BDS
  platform.

[SVN] BP r64041 - in trunk/BP/BP1.1/GrantleySocketPkg/Dxe/PciHostBridge
  MdeModulePkg/Bus/Pci/PciBusDxe is updatated to check return status of notify
  phase EfiPciHostBridgeEndEnumeration for PCI HOST Bridge Resource Allocation
  Protocol. Please update platform Host Bridge Dxe driver to handle
  EfiPciHostBridgeEndEnumeration correctly.

[SVN] BP r63967 - in trunk/BP/BP1.1/GrantleyPkg/Override
[SVN] BP r63970 - in trunk/BP/BP1.1/GrantleyPkg 
[SVN] BP r64042 - in trunk/BP/BP1.1/GrantleyPkg/Override
[SVN] BP r64056 - in trunk/BP/BP1.1/GrantleyPkg
  Removed the following files and directories and update DSC/FDF files 
accordingly
   trunk/BP/BP1.1/GrantleyPkg/Override/MdePkg/
   trunk/BP/BP1.1/GrantleyPkg/Override/MdeModulePkg/Core/
   trunk/BP/BP1.1/GrantleyPkg/Override/MdeModulePkg/Bus/Scsi/
   
trunk/BP/BP1.1/GrantleyPkg/Override/MdeModulePkg/Universal/FaultTolerantWriteDxe/
   
trunk/BP/BP1.1/GrantleyPkg/Override/BpCommonPkg/Bds/Library/LegacyBootManagerLib/
   trunk/BP/BP1.1/GrantleyPkg/Override/Restricted/ServerCommonPkg/
   trunk/BP/BP1.1/GrantleyPkg/Override/Restricted/IA32FamilyCpuPkg/Include/
   trunk/BP/BP1.1/GrantleyPkg/Override/Restricted/IA32FamilyCpuPkg/Library/
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/IA32FamilyCpuPkg.dsc
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/AcpiCpuData.h
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/CpuHotPlugData.h
   trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/Guid/
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/Library/CpuOnlyResetLib.h
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/Library/PlatformSecLib.h
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/Library/SmmCpuPlatformHookLib.h
   
trunk/BP/BP1.1/GrantleySocketPkg/Override/IA32FamilyCpuPkg/Include/Library/Socket

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Yao, Jiewen]

I am not sure how you did it for Ovmf.
In general, we use below way for real platform, for your information only.

1) In code boot, a DXE phase platform driver allocates OS-Reserved Memory type 
(EfiReservedType, or EfiAcpiNvs) for S3 PeiCore usage during code boot, and 
save address and length.
2) In S3 boot, MemoryInit module, it looks for this information, and install 
pei memory by using the saved information.
Then we can make sure all memory touched in S3 phase be reserved.

And AllocatePool *should* get memory there.

Thank you
Yao Jiewen


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, December 10, 2013 1:38 PM
To: Yao, Jiewen
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow 
preallocation of PEI_S3_RESUME_STATE

On 12/10/13 06:27, Yao, Jiewen wrote:
> If Ovmf "preallocate everything necessary in runtime services data
> *or* acpi NVS type areas for the S3 resume path", the all S3 
> AllocatePool or AllocatePages *should* be in those memory.
> 
> Would you please investigate why you cannot get memory reserved when 
> you call AllocatePool? You may dump Hob data structure to see where is 
> the available memory.
> 
> It might be a PeiCore issue (on memory management), or Ovmf issue (on 
> installing wrong memory location in S3 phase), per my understanding.

OK, then I guess OVMF does not install the right memory location (I assume you 
mean "pool") in S3 phase then. What should we do?

If I can specify an AcpiNVS memory range very early (in PlatformPei) and all 
AllocatePool() calls in PEI will just work off that (as a pool), that would be 
optimal.

Thanks
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Laszlo Ersek]

On 12/10/13 06:27, Yao, Jiewen wrote:
> If Ovmf "preallocate everything necessary in runtime services data
> *or* acpi NVS type areas for the S3 resume path", the all S3
> AllocatePool or AllocatePages *should* be in those memory.
> 
> Would you please investigate why you cannot get memory reserved when
> you call AllocatePool? You may dump Hob data structure to see where
> is the available memory.
> 
> It might be a PeiCore issue (on memory management), or Ovmf issue (on
> installing wrong memory location in S3 phase), per my understanding.

OK, then I guess OVMF does not install the right memory location (I
assume you mean "pool") in S3 phase then. What should we do?

If I can specify an AcpiNVS memory range very early (in PlatformPei) and
all AllocatePool() calls in PEI will just work off that (as a pool),
that would be optimal.

Thanks
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Laszlo Ersek]

On 12/10/13 05:59, Yao, Jiewen wrote:
> Clarify myself. I have question on the sentence below:
> "In that case the new allocation will fall outside of the permanent
> RAM area that may have been reserved from the OS, for example as ACPI
> NVS memory."
> 
> 1) ACPI Nvs is reserved from OS. BIOS *CAN* touch it.

Sure, we do. I don't recall claiming otherwise.

> 2) "the new allocation will fall outside of the permanent RAM area
> that may have been reserved from the OS", this should *never* happen
> according to current design. All memory touched by S3 should be
> reserved.
> If you observe it happen, we should investigate and root-cause it at first.

OK, here's the steps:

(1) I added a small loop to the beginning of S3RestoreConfig2() that
iterated over all of the memory allocation hobs, and dumped their types
and the covered ranges.

(2) When the patches that precede this one are in place, the above list
includes an ACPI NVS range that covers the permanent memory which has
been the target of the original temporary RAM migration. All HOBs that
had been allocated *before* the temporary RAM migration were covered by
said migration, and are sufficiently protected. (The protection is
established by the migration function itself, in patch "19/24" OvmfPkg:
S3 Resume: ensure survival of migrated PEI stack / heap).

(If either of patches 18/24 or 19/24 are missing, then the migration
target area, in permanent memory, ends up as boot services data, and the
OS will not stay away from it. Consequently, when we repeat the
temporary RAM migration to the same permanent area at S3 reboot, we'll
kill OS data. But I digress, this is not the question here.)

(3) The S3ResumeExecuteBootScript() function already has a statement
that logs the result of the AllocatePool() call:

  DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));

I compared the address logged here against the list of "protected" (ie.
acpi NVS / runtime services data) ranges from step 1. The address
reported here was not inside any one of those ranges, it was above the
highest one.

Which means that the EFI_HOB_TYPE_MEMORY_POOL-typed HOB backing the
allocation has been allocated in such permanent memory that is outside
of the temporary-to-permanent RAM migration *destination* area.
Consequently, I have not established protection for it (from the OS).
And, looking at the memory allocation HOB list from (1), noone else has
-- there is no memory allocation HOB at all (let alone one with a safe
enough memory type) that covers this address.

I certainly hope that I'm wrong, beause the thing that *I* can't
understand is how AllocatePool() calls could be permitted in
S3Resume2Pei() *at all*.

Thanks,
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Yao, Jiewen]

Hi Laszlo
If Ovmf "preallocate everything necessary in runtime services data *or* acpi 
NVS type areas for the S3 resume path", the all S3 AllocatePool or 
AllocatePages *should* be in those memory.

Would you please investigate why you cannot get memory reserved when you call 
AllocatePool? You may dump Hob data structure to see where is the available 
memory.

It might be a PeiCore issue (on memory management), or Ovmf issue (on 
installing wrong memory location in S3 phase), per my understanding.

Thank you
Yao Jiewen

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, December 10, 2013 1:14 PM
To: Yao, Jiewen
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow 
preallocation of PEI_S3_RESUME_STATE

On 12/10/13 05:51, Yao, Jiewen wrote:
> Hi Laszlo
> Would you please clarify your concern? Does that real happen on some 
> platforms? Or Do you think it MIGHT happen?
> 
> If it does happen, would please clarify on which platform and why?
> 
> I am trying to understand that...

Please see the next patch -- the PCD / feature introduced here is immediately 
put to use in the next patch, in OVMF.

In OVMF the PEI phase runs from RAM. The flash only contains SEC, and a 
compressed image. The compressed image (including all PEI, DXE, SMM, and UEFI 
drivers etc) is decompressed by SEC from flash to a RAM area. This happens 
after both cold boot and on the S3 resume path.

In order for the S3 resume path not to trample over OS memory, we do two
things:
- after cold boot, we preallocate everything necessary in runtime services data 
*or* acpi NVS type areas for the S3 resume path. This way the OS won't touch 
these areas.
- on the S3 Resume path, we can only use
  (a) globals (static storage duration)
  (b) stack (auto storage duration)
  (c) preallocated areas from the previous step.

Because we must not touch memory that we haven't announced to the OS before. 
This excludes dynamic allocation.

(a) is properly protected (globals are part of the driver images decompressed 
by SEC), but it is only usable with sub-modules that are owned by OvmfPkg. 
Other sub-modules could be running from flash and globals in them may not be 
writable.

(b) is generally good, but only for small areas, and it is unusable in this 
specific case, because we're munging the stack manually.

Thanks,
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Laszlo Ersek]

On 12/10/13 05:51, Yao, Jiewen wrote:
> Hi Laszlo
> Would you please clarify your concern? Does that real happen on some 
> platforms? Or Do you think it MIGHT happen?
> 
> If it does happen, would please clarify on which platform and why?
> 
> I am trying to understand that...

Please see the next patch -- the PCD / feature introduced here is
immediately put to use in the next patch, in OVMF.

In OVMF the PEI phase runs from RAM. The flash only contains SEC, and a
compressed image. The compressed image (including all PEI, DXE, SMM, and
UEFI drivers etc) is decompressed by SEC from flash to a RAM area. This
happens after both cold boot and on the S3 resume path.

In order for the S3 resume path not to trample over OS memory, we do two
things:
- after cold boot, we preallocate everything necessary in runtime
services data *or* acpi NVS type areas for the S3 resume path. This way
the OS won't touch these areas.
- on the S3 Resume path, we can only use
  (a) globals (static storage duration)
  (b) stack (auto storage duration)
  (c) preallocated areas from the previous step.

Because we must not touch memory that we haven't announced to the OS
before. This excludes dynamic allocation.

(a) is properly protected (globals are part of the driver images
decompressed by SEC), but it is only usable with sub-modules that are
owned by OvmfPkg. Other sub-modules could be running from flash and
globals in them may not be writable.

(b) is generally good, but only for small areas, and it is unusable in
this specific case, because we're munging the stack manually.

Thanks,
Laszlo

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Yao, Jiewen]

Clarify myself. I have question on the sentence below:
"In that case the new allocation will fall outside of the permanent RAM area 
that may have been reserved from the OS, for example as ACPI NVS memory."

1) ACPI Nvs is reserved from OS. BIOS *CAN* touch it.
2) "the new allocation will fall outside of the permanent RAM area that may 
have been reserved from the OS", this should *never* happen according to 
current design. All memory touched by S3 should be reserved.
If you observe it happen, we should investigate and root-cause it at first.

Thank you
Yao Jiewen

-Original Message-
From: Yao, Jiewen 
Sent: Tuesday, December 10, 2013 12:52 PM
To: edk2-devel@lists.sourceforge.net
Subject: RE: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow 
preallocation of PEI_S3_RESUME_STATE

Hi Laszlo
Would you please clarify your concern? Does that real happen on some platforms? 
Or Do you think it MIGHT happen?

If it does happen, would please clarify on which platform and why?

I am trying to understand that...

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, December 10, 2013 11:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of 
PEI_S3_RESUME_STATE

This patch enables S3Resume2Pei to eliminate an could be invalid during S3 
Resume.

The concrete implementation allocates memory from the HOB heap:

S3ResumeExecuteBootScript() [UefiCpuPkg/.../S3Resume2Pei/S3Resume.c]
  AllocatePool() [MdePkg/Library/PeiMemoryAllocationLib]
PeiServicesAllocatePool() [MdePkg/Library/PeiServicesLib]
  PeiAllocatePool() [MdeModulePkg/Core/Pei/Memory/MemoryServices.c]
PeiServicesCreateHob(EFI_HOB_TYPE_MEMORY_POOL)

but we might already be past the migration from temporary RAM to permanent RAM. 
In that case the new allocation will fall outside of the permanent RAM area 
that may have been reserved from the OS, for example as ACPI NVS memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 1 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 5 -
 UefiCpuPkg/UefiCpuPkg.dec   | 7 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index db5d66e..85d6d3d 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -85,6 +85,7 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState
 
 [Depex]
   TRUE
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 426eef7..c5a3b66 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -851,7 +851,10 @@ S3ResumeExecuteBootScript (
   //
   // Prepare data for return back
   //
-  PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));
+  PeiS3ResumeState = (VOID *)(UINTN)PcdGet64 (PcdPeiS3ResumeState);  if 
+ (PeiS3ResumeState == NULL) {
+PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));  }
   ASSERT (PeiS3ResumeState != NULL);
   DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index 
b3858b1..d962ef6 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -44,3 +44,10 @@
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress|0xfee0|UINT32|0x0001
 
+[PcdsDynamic, PcdsDynamicEx]
+  ## The following PCD controls the allocation of "PeiS3ResumeState" in
+  #  S3ResumeExecuteBootScript()
+  #  [UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c]. When left at 
+NULL,
+  #  "PeiS3ResumeState" will be allocated with AllocatePool(). 
+Otherwise the
+  #  address specified in the PCD will be assigned to "PeiS3ResumeState".
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState|0x0|UINT64|0x0002
--
1.8.3.1



--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_

Re: [edk2] [PATCH v5 0/8] OvmfPkg/Arm*Pkg: Introduce and use the new VIRTIO_DEVICE_PROTOCOL protocol

[Laszlo Ersek]

On 11/27/13 20:10, Laszlo Ersek wrote:
> Testing:
> 
> - OvmfPkg, X64:
>   - VirtioNetDxe:
> - PXE boot on libvirt's virtual network
> - DataSource socket utility from AppPkg (guest to host)
>   - VirtioBlkDxe: booted
> - Fedora 19
> - Windows 2012 R2
> - Windows 2008 R2 (SeaBIOS CSM build of OVMF)
>   - VirtioScsiDxe: booted
> - RHEL-6
> 
> - ArmVExpress-RTSM-AEMv8Ax4-foundation, Aarch64 Foundation model:
>   - VirtioBlkDxe: booted
> - Linaro OpenEmbedded 13.10 image (semihosting + virtio-blk)
> - Linaro OpenEmbedded 13.10 image (virtio-blk only)
> - Fedora 19 image (with EFI stub, virtio-blk only)
> 
> Notes:
> - Kept Olivier's C-u and S-o-b in the first place everywhere.
> - When I touched a patch, I added my changes below Olivier's S-o-b, and
>   added my own C-u and S-o-b too.
> - When I didn't touch a patch, and Jordan was explicitly OK with it (as
>   in, R-b), I added his R-b.
> 
> Summary list of changes in v5 (in the order visible in the squashed diff
> below; patches contain broken out v4->v5 lists):
> 
> - VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency
> - VirtioFlush(): update comment block in VirtioLib.[hc]; error code is
>   propagated from VirtIo->SetQueueNotify().
> - typo fix in VirtioMmioInstallDevice() comment block
> - add disclaimer (two instances) about the protocol being work in
>   progress
> - ensure / document that the VIRTIO_BLK_DEVICE_PATH structure must be
>   packed
> - fix whitespace damage in definition of "mVirtioBlockDevicePath"
> - plug MmioDevice leak in VirtioMmioUninstallDevice()
> - return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if
>   QueueAddress is NULL
> - VirtioMmioSetQueueSize(): fix return value (it's a status code)
> - VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus
>   EFI_UNSUPPORTED, rather than ASSERT()
> - VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant
>   (FieldSize > 8) checks
> - VirtioBlkInit(): jump to Failed label if SetPageSize() fails
> - VirtioBlkInit(): fixup comment, and add error handling, near
>   SetQueueNum() call
> - VirtioBlkDriverBindingStart(): remove redundant (always false) check
>   for a subsystem device ID different from
>   VIRTIO_SUBSYSTEM_BLOCK_DEVICE; VirtioBlkDriverBindingSupported()
>   handles it already
> - VirtioNetGetFeatures(): update stale comment block
> - VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded
>   loop)
> - VirtioNetDriverBindingStart(): remove redundant (always false) check
>   for a subsystem device ID different from
>   VIRTIO_SUBSYSTEM_NETWORK_CARD; VirtioNetDriverBindingSupported()
>   handles it already
> - VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper
>   MMIO operation
> - VirtioNetInitialize(): fix destination error label for when
>   SetPageSize() fails
> - VirtioPciIoRead(): restore the original requirement that FieldSize
>   equal BufferSize exactly (not only divide it). The looping added in v4
>   did not match the comment block, and the only place that used it in v4
>   (ie. VirtioNetGetFeatures()) needs an open-coded loop anyway (will be
>   done in a later part of v5).
> - updated comment block on VirtioPciDeviceRead()
> - return EFI_UNSUPPORTED instead of failed ASSERT() in
>   VirtioPciSetPageSize()
> - VirtioScsi.c: fix comment block of
>   VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ()
> - VirtioScsiInit(): fix destination error label for when SetPageSize()
>   fails
> - VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper
>   MMIO operation
> 
> Changes not visible in the squashed diff (because the end result is the
> same in both v4 and v5):
> 
> - ArmPlatformPkg/ArmVExpressPkg: Added the empty 'ArmFvpDxe' platform
>   UEFI driver:
>   - For uniformity, add the empty driver to
> ArmVExpress-RTSM-AEMv8Ax4-foundation.* too in this patch, not just
> ArmVExpress-RTSM-AEMv8Ax4.*. V4 added the empty driver to
> ArmVExpress-RTSM-AEMv8Ax4-foundation.* not sooner than the next
> patch, fusing it with other (= virtio) functionality. Let's split
> these changes cleanly.
> 
> - ArmPlatformPkg/ArmFvpDxe: Added Virtio Block support:
>   - the platform driver is added to all platform DSC and FDF files in
> the previous patch; this patch focuses on virtio only

Ping :)

Thanks
Laszlo


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Yao, Jiewen]

Hi Laszlo
Would you please clarify your concern? Does that real happen on some platforms? 
Or Do you think it MIGHT happen?

If it does happen, would please clarify on which platform and why?

I am trying to understand that...

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, December 10, 2013 11:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of 
PEI_S3_RESUME_STATE

This patch enables S3Resume2Pei to eliminate an could be invalid during S3 
Resume.

The concrete implementation allocates memory from the HOB heap:

S3ResumeExecuteBootScript() [UefiCpuPkg/.../S3Resume2Pei/S3Resume.c]
  AllocatePool() [MdePkg/Library/PeiMemoryAllocationLib]
PeiServicesAllocatePool() [MdePkg/Library/PeiServicesLib]
  PeiAllocatePool() [MdeModulePkg/Core/Pei/Memory/MemoryServices.c]
PeiServicesCreateHob(EFI_HOB_TYPE_MEMORY_POOL)

but we might already be past the migration from temporary RAM to permanent RAM. 
In that case the new allocation will fall outside of the permanent RAM area 
that may have been reserved from the OS, for example as ACPI NVS memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 1 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 5 -
 UefiCpuPkg/UefiCpuPkg.dec   | 7 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index db5d66e..85d6d3d 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -85,6 +85,7 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState
 
 [Depex]
   TRUE
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 426eef7..c5a3b66 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -851,7 +851,10 @@ S3ResumeExecuteBootScript (
   //
   // Prepare data for return back
   //
-  PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));
+  PeiS3ResumeState = (VOID *)(UINTN)PcdGet64 (PcdPeiS3ResumeState);  if 
+ (PeiS3ResumeState == NULL) {
+PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));  }
   ASSERT (PeiS3ResumeState != NULL);
   DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index 
b3858b1..d962ef6 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -44,3 +44,10 @@
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress|0xfee0|UINT32|0x0001
 
+[PcdsDynamic, PcdsDynamicEx]
+  ## The following PCD controls the allocation of "PeiS3ResumeState" in
+  #  S3ResumeExecuteBootScript()
+  #  [UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c]. When left at 
+NULL,
+  #  "PeiS3ResumeState" will be allocated with AllocatePool(). 
+Otherwise the
+  #  address specified in the PCD will be assigned to "PeiS3ResumeState".
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState|0x0|UINT64|0x0002
--
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC v2 21/24] UefiCpuPkg: S3Resume2Pei: align return stacks explicitly

[Yao, Jiewen]

Thanks for the patch.

Reviewed by: Jiewen Yao 


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, December 10, 2013 11:56 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [RFC v2 21/24] UefiCpuPkg: S3Resume2Pei: align return stacks 
explicitly

S3RestoreConfig2() can optionally stack-switch to the SMM S3 Resume Entry Point 
and ask it to transfer to S3ResumeExecuteBootScript().

Similarly, S3ResumeExecuteBootScript() stack-switches explicitly to the boot 
script executor, and asks it to transfer to S3ResumeBootOs().

Currently the stack pointers specified for the SMM S3 Resume Entry Point and 
the boot script executor to use for returning are derived from addresses of the 
first local variables in S3RestoreConfig2() and S3ResumeExecuteBootScript(), 
respectively.

Since (theoretically) the stack grows down as local variables are defined and 
functions are called, the idea is presumably to allow the respective callee to 
overwrite the caller's local variables. (The callees in question can never 
return normally, only by explicit stack switching.)

Taking the address of "Status" is less portable than optimal however.
Compilers are free to juggle local variables at build time as they please, 
including order and alignment on the stack. For example, when the code is built 
for 64-bit PEI with gcc-4.8.2, the address of "Status" trips up the alignment 
assertion in SwitchStack().

Let's align the address of "Status" down to CPU_STACK_ALIGNMENT explicitly. If 
a compiler ensures such alignment and places "Status" at the highest address 
automatically, then this change has no effect.
Otherwise, we'll prepare ReturnStackPointer values that (a) are correctly 
aligned, (b) preserve the same amount or more (but never less) from the 
caller's local variables than before, which should be safe.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index e57398b..426eef7 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -733,6 +733,16 @@ RestoreS3PageTables (  }
 
 /**
+  This macro aligns the address of a variable with auto storage 
+ duration down  to CPU_STACK_ALIGNMENT.
+
+  Since the stack grows downward, the result preserves more of the 
+stack than
+  the original address (or the same amount), not less.
+**/
+#define STACK_ALIGN_DOWN(Ptr) \
+  ((UINTN)(Ptr) & ~(UINTN)(CPU_STACK_ALIGNMENT - 1))
+
+/**
   Jump to boot script executor driver.
 
   The function will close and lock SMRAM and then jump to boot script execute 
driver to executing S3 boot script table.
@@ -846,7 +856,7 @@ S3ResumeExecuteBootScript (
   DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
   PeiS3ResumeState->ReturnEntryPoint   = 
(EFI_PHYSICAL_ADDRESS)(UINTN)S3ResumeBootOs;
-  PeiS3ResumeState->ReturnStackPointer = (EFI_PHYSICAL_ADDRESS)(UINTN)&Status;
+  PeiS3ResumeState->ReturnStackPointer = 
+ (EFI_PHYSICAL_ADDRESS)STACK_ALIGN_DOWN (&Status);
   //
   // Save IDT
   //
@@ -1038,7 +1048,7 @@ S3RestoreConfig2 (
 SmmS3ResumeState->ReturnEntryPoint   = 
(EFI_PHYSICAL_ADDRESS)(UINTN)S3ResumeExecuteBootScript;
 SmmS3ResumeState->ReturnContext1 = 
(EFI_PHYSICAL_ADDRESS)(UINTN)AcpiS3Context;
 SmmS3ResumeState->ReturnContext2 = 
(EFI_PHYSICAL_ADDRESS)(UINTN)EfiBootScriptExecutorVariable;
-SmmS3ResumeState->ReturnStackPointer = 
(EFI_PHYSICAL_ADDRESS)(UINTN)&Status;
+SmmS3ResumeState->ReturnStackPointer = 
+ (EFI_PHYSICAL_ADDRESS)STACK_ALIGN_DOWN (&Status);
 
 DEBUG (( EFI_D_ERROR, "SMM S3 Signature= %x\n", 
SmmS3ResumeState->Signature));
 DEBUG (( EFI_D_ERROR, "SMM S3 Stack Base   = %x\n", 
SmmS3ResumeState->SmmS3StackBase));
--
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 16/24] OvmfPkg: S3 Resume: reserve fw decompression scratch space from the OS

[Laszlo Ersek]

This area is also overwritten by SEC when it decompresses the main
firmware -- tell the OS to stay away.

 +--+ 8M  (PcdOvmfMemFvBase)
   ^ |  |
final decompr. | +--+ 9M  (OutputBuffer)
target,|   ^ |  |
reserved by|   | |  |
prev. patch| temporary | |  |
   v decompression | |  |
 output| +--+ 16M (PcdOvmfMemFvBase +
   ^   | |  |  PcdOvmfMemFvSize)
   |   v |  |
   | +--+ 17M+80  (OutputBuffer +
  reserved |   ^ |  |  OutputBufferSize)
  now  |unused | |  |
   |   v |  |
   | +--+ 18M (ScratchBuffer)
   |   ^ |  |
   |  decompr. scratch | |  |
   v   v |  |
 +--+ 18M+64K (ScratchBuffer +
   ScratchBufferSize)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/Fv.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index 4f1ad16..4a31cc3 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/PlatformPei/Fv.c
@@ -54,6 +54,18 @@ PeiFvInitialization (
 EfiACPIMemoryNVS
 );
 
+  //
+  // Firmware decompression in DecompressGuidedFv() [OvmfPkg/Sec/SecMain.c]
+  // uses additional temporary memory.
+  //
+  BuildMemoryAllocationHob (
+PcdGet32 (PcdOvmfMemFvBase) + PcdGet32 (PcdOvmfMemFvSize),
+(SIZE_2MB  + // cover the end of OutputBuffer, rounded up to 1MB
+ SIZE_64KB   // cover the end of ScratchBuffer
+ ),
+EfiACPIMemoryNVS
+);
+
   return EFI_SUCCESS;
 }
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 18/24] MdeModulePkg: DxeLoad: UpdateStackHob(): honor original allocation type

[Laszlo Ersek]

The unique Stack HOB describes the initial memory area used as stack and
PEI heap.

UpdateStackHob() -- called by the various platforms' HandOffToDxeCore()
functions -- modifies this HOB before it is passed to the DXE phase. The
UpdateStackHob() function repoints the Stack HOB at the memory area that
the DXE phase will actually use as stack.

However, as the function explains, the original area must be kept around
as well (DXE must not reclaim it), because  "some PEIMs may [...] keep key
information on the stack". For this end, UpdateStackHob() creates a new
memory allocation HOB that covers the original area.

Currently, the new memory allocation HOB doesn't honor / mirror the
original memory allocation type; it describes the old area invariably as
EfiBootServicesData. Normally this is alright, but it causes problems if
the original stack area was destined for a lifetime longer than
EfiBootServicesData, for example EfiACPIMemoryNVS.

Change UpdateStackHob() so that it preserves not only the boundaries of
the original area, but its allocation type too, in the new HOB.

The patch makes no visible difference if the original allocation type too
was EfiBootServicesData.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c 
b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
index aa05076..a67aa88 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
@@ -743,13 +743,14 @@ UpdateStackHob (
   BuildMemoryAllocationHob (
 Hob.MemoryAllocationStack->AllocDescriptor.MemoryBaseAddress,
 Hob.MemoryAllocationStack->AllocDescriptor.MemoryLength,
-EfiBootServicesData
+Hob.MemoryAllocationStack->AllocDescriptor.MemoryType
 );
   //
   // Update the BSP Stack Hob to reflect the new stack info.
   //
   Hob.MemoryAllocationStack->AllocDescriptor.MemoryBaseAddress = 
BaseAddress;
   Hob.MemoryAllocationStack->AllocDescriptor.MemoryLength = Length;
+  Hob.MemoryAllocationStack->AllocDescriptor.MemoryType = 
EfiBootServicesData;
   break;
 }
 Hob.Raw = GET_NEXT_HOB (Hob);
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 04/24] OvmfPkg: S3 Suspend: pull in SmmLockBox driver

[Laszlo Ersek]

"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf" produces
gEfiSmmLockBoxCommunicationGuid, implementing LockBox services in SMRAM
for the SmmLockBoxLib library (used in the following patches).

  gEfiSmmLockBoxCommunicationGuid
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]

This is the "trusted" SMM driver that verifies and serves SMRAM change
requests from "untrusted" / 3rd party DXE drivers.

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 351ec73..62a660d 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -268,6 +268,14 @@
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
 
+[LibraryClasses.common.DXE_SMM_DRIVER]
+  
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
+
 

 #
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform.
@@ -509,6 +517,7 @@
   OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
   MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
 
   #
   # ACPI Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 34cf4ed..4edefee 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -366,6 +366,7 @@ INF  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 INF  OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+INF  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
 
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -548,3 +549,11 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
 UI   STRING="$(MODULE_NAME)" Optional
 VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
   }
+
+[Rule.Common.DXE_SMM_DRIVER]
+  FILE DRIVER = $(NAMED_GUID) {
+DXE_DEPEXDXE_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)
+  }
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 02/24] OvmfPkg: S3 Suspend: introduce EmuSmmDxe for emulating SMRAM

[Laszlo Ersek]

This mostly no-op runtime DXE driver produces the EFI_SMM_ACCESS2_PROTOCOL
and EFI_SMM_CONTROL2_PROTOCOL protocols, enabling the SMM core to be
loaded in the next patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf |  55 
 OvmfPkg/EmuSmmDxe/EmuSmmDxe.c   | 276 
 OvmfPkg/OvmfPkgX64.dsc  |   5 +
 OvmfPkg/OvmfPkgX64.fdf  |   2 +
 4 files changed, 338 insertions(+)
 create mode 100644 OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
 create mode 100644 OvmfPkg/EmuSmmDxe/EmuSmmDxe.c

diff --git a/OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf b/OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
new file mode 100644
index 000..8cae943
--- /dev/null
+++ b/OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
@@ -0,0 +1,55 @@
+## @file
+# This module emulates SMRAM by providing EFI_SMM_ACCESS2_PROTOCOL and
+# EFI_SMM_CONTROL2_PROTOCOL.
+#
+# Copyright (C) 2013, 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  = EmuSmmDxe
+  FILE_GUID  = C993C48A-9EEC-4BBD-93B0-276ED216CD11
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  ENTRY_POINT= EmuSmmDxeEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  EmuSmmDxe.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  DebugLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiSmmAccess2ProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
+  gEfiSmmControl2ProtocolGuid  # PROTOCOL ALWAYS_PRODUCED
+
+[Guids]
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaSize
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/EmuSmmDxe/EmuSmmDxe.c b/OvmfPkg/EmuSmmDxe/EmuSmmDxe.c
new file mode 100644
index 000..92adccd
--- /dev/null
+++ b/OvmfPkg/EmuSmmDxe/EmuSmmDxe.c
@@ -0,0 +1,276 @@
+/** @file
+
+  This module emulates SMRAM by providing EFI_SMM_ACCESS2_PROTOCOL and
+  EFI_SMM_CONTROL2_PROTOCOL.
+
+  Copyright (C) 2013, Red Hat, Inc.
+
+  Copyright (c) 2009 - 2010, 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 
+
+
+STATIC EFI_SMM_ACCESS2_PROTOCOL mAccess2;
+
+
+/**
+  Opens the SMRAM area to be accessible by a boot-service driver.
+
+  This function "opens" SMRAM so that it is visible while not inside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM. The function should return EFI_DEVICE_ERROR if the SMRAM
+  configuration is locked.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot be opened, perhaps because it is
+locked.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+EmuSmmAccess2Open (
+  IN EFI_SMM_ACCESS2_PROTOCOL  *This
+  )
+{
+  //
+  // Normally we'd like to return EFI_UNSUPPORTED here (the PI spec allows it
+  // and our SMRAM is always visible), but the EFI_SMM_COMMUNICATION_PROTOCOL
+  // implementation in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c" really wants
+  // this function to succeed.
+  //
+  if (mAccess2.LockState) {
+return EFI_DEVICE_ERROR;
+  }
+  mAccess2.OpenState = TRUE;
+  return EFI_SUCCESS;
+}
+
+
+/**
+  Inhibits access to the SMRAM.
+
+  This function "closes" SMRAM so that it is not visible while outside of SMM.
+  The function should return EFI_UNSUPPORTED if the hardware does not support
+  hiding of SMRAM.
+
+  @param[in] This   The EFI_SMM_ACCESS2_PROTOCOL instance.
+
+  @retval EFI_SUCCESS   The operation was successful.
+  @retval EFI_UNSUPPORTED   The system does not support opening and closing of
+SMRAM.
+  @retval EFI_DEVICE_ERROR  SMRAM cannot b

[edk2] [RFC v2 00/24] S3 suspend/resume for OVMF (WIP)

[Laszlo Ersek]

I can (*) resume a Fedora 19 guest with this.

(*) Almost.

(And now that everyone is listening, let's talk about the problems :))

v1->v2:

- Rebase:
  - "MdeModulePkg: SmmLockBox: remove wrong DepEx" has been applied.
  - Series is on top of Wei's Xen series now.

- Old patch:
  "OvmfPkg: PlatformPei: reserve RAM as SMRAM backing":
  - fixup param list in ReserveEmuSmmArea() function definition.

- New patch:
  "OvmfPkg: S3 Suspend: save boot script after ACPI context":
  - The "big problem" of v1 about EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL not
being installed by anyone has been solved -- save the boot script
inside the OVMF specific EFI_ACPI_S3_SAVE_PROTOCOL implementation.

- Old patch:
  "OvmfPkg: S3 Resume: detect S3 Resume in CMOS and set boot mode
  accordingly"
  - Redraw data flow diagram between suspend and resume according to
new, OVMF-internal installation of
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL; see above.

- After Paolo had proved (thanks!) that the S3 resume trampoline in
  "MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S" worked
  correctly on KVM too, I started protecting the OS's RAM:


On 12/04/13 18:17, Jordan Justen wrote:
> I can think of one *major* issue for OVMF S3. We run PEI from RAM.
> This allows allows us to compress the PEI code.
>
> Therefore, on S3 resume, we will overwrite a big chunk of memory when
> we decompress the main FV. This is going to trash a big chunk of RAM
> likely used by the OS. It starts at PcdOvmfMemFvBase and has a size of
> PcdOvmfMemFvSize + 2MB. (The 2MB is actually closer to 1MB, and is
> some extra RAM used during decompression).
>
> Oh, and one other chunk of RAM we use is SEC/PEI Temporary RAM at
> 0x7-0x8. (SecMain.c SecCoreStartupWithStack)
>
> I guess the first quick hack would be to reserve these memory ranges
> so the OS will not use them. (EfiACPIMemoryNVS) [...]

The following patches are new and concern themselves with this problem:

  OvmfPkg: S3 Resume: reserve decompressed firmware area from the OS
  OvmfPkg: S3 Resume: reserve fw decompression scratch space from the OS
  OvmfPkg: S3 Resume: reserve initial (pre-migr.) SEC/PEI stack and PEI heap
  MdeModulePkg: DxeLoad: UpdateStackHob(): honor original allocation type
  OvmfPkg: S3 Resume: ensure survival of migrated PEI stack / heap
  OvmfPkg: S3 Resume: flatten DXEFV into MAINFV
  UefiCpuPkg: S3Resume2Pei: align return stacks explicitly
  UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE
  OvmfPkg: S3 Resume: preallocate PEI_S3_RESUME_STATE for S3Resume2Pei

I've written these new patches in the following manner:
- Logged all memory allocation HOBs at the beginning of
  S3RestoreConfig2().

- For each memory allocation HOB describing a memory type different
  from EfiACPIMemoryNVS and EfiRuntimeServicesData, I tracked down the
  origin of the allocation, and adapted it to S3 resume.

- Modified MdePkg/Library/PeiMemoryAllocationLib to emit WARNINGs for
  EfiBootServicesData requests. Tracked down all such warnings that were
  emitted after entering S3RestoreConfig2() (ie. on the resume path).

Good news: x86_64 Fedora 19 guest can be suspended and "resumed", as in:
- I can log in and issue commands over the serial console.
- I can access the virtio-blk disk.
- The dmesg before and after suspend and resume looks generally
  sensible.
- The "shutdown -h now" command tends to work.

Bad news:
- The screen remains dead (independently of cirrus vs. stdvga, and
  independently of efifb console vs. X11 GUI).
- virtnet_restore() seems to reliably trigger "list_add corruption" in
  the kernel. Maybe a virtio-net resume bug in Linux, maybe we're
  corrupting OS memory.
- Resume is generally unstable. Sometimes it looks perfect, sometimes a
  bunch of userspace processes start dumping core immediately after
  resume (probably some memory overwrites left untracked...)
- When X11 is running (let alone the resume is started from the GUI),
  the stability worsens greatly.

I think we could discuss the series at this point. It is available under
 too.

Thanks,
Laszlo

Laszlo Ersek (24):
  OvmfPkg: PlatformPei: reserve RAM as SMRAM backing store
  OvmfPkg: S3 Suspend: introduce EmuSmmDxe for emulating SMRAM
  OvmfPkg: S3 Suspend: pull in DXE driver for
EFI_SMM_COMMUNICATION_PROTOCOL
  OvmfPkg: S3 Suspend: pull in SmmLockBox driver
  OvmfPkg: S3 Suspend: use SMM instances for LockBoxLib library class
  OvmfPkg: S3 Suspend: import specialized copy of AcpiS3SaveDxe
  OvmfPkg: S3 Suspend: save ACPI context
  OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script
  OvmfPkg: S3 Suspend: save boot script after ACPI context
  OvmfPkg: PlatformPei: reserve storage for disclosing SMST
  OvmfPkg: S3 Suspend: introduce DiscloseSmstSmm driver
  OvmfPkg: S3 Resume: introduce EmuSmmPei for emulating SMRAM in PEI
  OvmfPkg: S3 Resu

[edk2] [RFC v2 15/24] OvmfPkg: S3 Resume: reserve decompressed firmware area from the OS

[Laszlo Ersek]

This area is overwritten after resume / reboot. Make sure the OS steers
clear of it so that we don't destroy OS data after resume.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/Fv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index f389e27..4f1ad16 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/PlatformPei/Fv.c
@@ -45,12 +45,13 @@ PeiFvInitialization (
   BuildFvHob (PcdGet32 (PcdOvmfMemFvBase), PcdGet32 (PcdOvmfMemFvSize));
 
   //
-  // Create a memory allocation HOB.
+  // Cover the decompressed main firmware with a memory allocation that
+  // prevents the OS from using it. At S3 resume we overwrite this area.
   //
   BuildMemoryAllocationHob (
 PcdGet32 (PcdOvmfMemFvBase),
 PcdGet32 (PcdOvmfMemFvSize),
-EfiBootServicesData
+EfiACPIMemoryNVS
 );
 
   return EFI_SUCCESS;
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 12/24] OvmfPkg: S3 Resume: introduce EmuSmmPei for emulating SMRAM in 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.

Unfortunately, when SmmLockBoxPeiLib does the parsing itself, it needs a
pointer to the SMST. SMM data is strongly protected from non-SMM drivers
-- the intent is that SMM data cannot be fetched from the outside, except
through the validated Communication interfaces (DXE protocol or PPI).

Hence, both ways SmmLockBoxPeiLib could work are rough -- either a full
EFI_PEI_SMM_COMMUNICATION_PPI infrastructure would have to be built (edk2
contains none) that switches diligently between trusted SMM and untrusted
third party PEIMs, or SmmLockBoxPeiLib needs access to the SMST saved from
before S3 Suspend (which expressly conflicts with the intent of SMM).

This driver retrieves the address of the SMST leaked by the
DiscloseSmstSmm driver, and passes it as a GUIDed HOB to S3Resume2Pei
(added later in the series). S3Resume2Pei is the PEIM that exercises
SmmLockBoxPeiLib.

The load / installation order of S3Resume2Pei and EmuSmmPei is
indifferent. EmuSmmPei 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/EmuSmmPei/EmuSmmPei.inf |  60 +
 OvmfPkg/EmuSmmPei/EmuSmmPei.c   | 285 
 OvmfPkg/OvmfPkgX64.dsc  |   4 +
 OvmfPkg/OvmfPkgX64.fdf  |   1 +
 4 files changed, 350 insertions(+)
 create mode 100644 OvmfPkg/EmuSmmPei/EmuSmmPei.inf
 create mode 100644 OvmfPkg/EmuSmmPei/EmuSmmPei.c

diff --git a/OvmfPkg/EmuSmmPei/EmuSmmPei.inf b/OvmfPkg/EmuSmmPei/EmuSmmPei.inf
new file mode 100644
index 000..bbdb5e0
--- /dev/null
+++ b/OvmfPkg/EmuSmmPei/EmuSmmPei.inf
@@ -0,0 +1,60 @@
+## @file
+# PEI module emulating SMRAM access by producing PEI_SMM_ACCESS_PPI and
+# EFI_PEI_SMM_COMMUNICATION_PPI.
+#
+# Copyright (C) 2013, 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  = EmuSmmPei
+  FILE_GUID  = F50DB7D2-FAD9-4E89-A8B4-BC4218C4D025
+  MODULE_TYPE= PEIM
+  VERSION_STRING = 1.0
+  ENTRY_POINT= EmuSmmPeiEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64 IPF EBC
+#
+
+[Sources]
+  EmuSmmPei.c
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[Guids]
+  gEfiAcpiVariableGuid
+
+[LibraryClasses]
+  BaseMemoryLib
+  DebugLib
+  HobLib
+  PcdLib
+  PeiServicesLib
+  PeimEntryPoint
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdDiscloseSmstPtrPtr
+
+[Ppis]
+  gEfiPeiSmmCommunicationPpiGuid # PPI ALWAYS_PRODUCED
+  gPeiSmmAccessPpiGuid   # PPI ALWAYS_PRODUCED
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/EmuSmmPei/EmuSmmPei.c b/OvmfPkg/EmuSmmPei/EmuSmmPei.c
new file mode 100644
index 000..82ada54
--- /dev/null
+++ b/OvmfPkg/EmuSmmPei/EmuSmmPei.c
@@ -0,0 +1,285 @@
+/** @file
+
+  PEI module emulating SMRAM access by producing PEI_SMM_ACCESS_PPI and
+  EFI_PEI_SMM_COMMUNICATION_PPI.
+
+  Copyright (C) 2013, Red Hat, Inc.
+
+  Copyright (c) 2010, 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 
+#include 
+#include 
+#include 
+
+/**
+  Communicates with a registered handler.
+
+  

[edk2] [RFC v2 10/24] OvmfPkg: PlatformPei: reserve storage for disclosing SMST

[Laszlo Ersek]

In the next patch we'll add a driver that exposes the SMM System
Management System Table (normally only accessible in SMM) to the world.

For this purpose we allocate a PCD called PcdDiscloseSmstPtrPtr that
contains a pointer to the pointer to the SMST.

PCD value,  pointer to
lost at warm  --->  SMST in runtime  --->  SMST: also survives
reboot but  storage:
recreated   survives warm
with same   reboot
value   (reallocated
in same spot)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf | 1 +
 OvmfPkg/PlatformPei/Platform.c  | 4 
 OvmfPkg/OvmfPkg.dec | 5 +
 3 files changed, 10 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 8811542..028a640 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -63,6 +63,7 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaSize
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdDiscloseSmstPtrPtr
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 4bce240..2616757 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -393,6 +393,10 @@ ReserveEmuSmmArea (
   Address = AllocateRuntimePool (AreaSize);
   ASSERT (Address != NULL);
   PcdSet64 (PcdEmuSmmAreaBase, (UINT64)(UINTN) Address);
+
+  Address = AllocateRuntimePool (sizeof (UINT64));
+  ASSERT (Address != NULL);
+  PcdSet64 (PcdDiscloseSmstPtrPtr, (UINT64)(UINTN) Address);
 }
 
 
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 21105ad..cfc0fc3 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -94,5 +94,10 @@
   #  bitnesses.
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase|0x0|UINT64|0x12
 
+  ## The DiscloseSmstSmm SMM driver stores the address of the System Management
+  #  System Table in the location pointed to by this PCD. The EmuSmmPei PEIM
+  #  fetches the SMST address from the same location.
+  gUefiOvmfPkgTokenSpaceGuid.PcdDiscloseSmstPtrPtr|0x0|UINT64|0x13
+
 [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 24/24] OvmfPkg: S3 Resume: detect S3 Resume in CMOS and set boot mode accordingly

[Laszlo Ersek]

Data is transferred between S3 Suspend and S3 Resume as follows:

S3 Suspend (DXE):

(1) BdsLibBootViaBootOption()
  EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
  - saves ACPI S3 Context to SMRAM LockBox  ---+
(including FACS address -- FACS ACPI table |
contains OS waking vector) |
   |
  - prepares boot script:  |
EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe]|
  S3BootScriptLib [PiDxeS3BootScriptLib]   |
  - opcodes & arguments are saved in NVS.  --+ |
 | |
  - issues a notification by installing  | |
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL   | |
 | |
(2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe]  | |
  S3BootScriptLib [PiDxeS3BootScriptLib] | |
  - closes script with special opcode  <-+ |
  - script is available in non-volatile memory |
via PcdS3BootScriptTablePrivateDataPtr  --+|
  ||
BootScriptExecutorDxe ||
  S3BootScriptLib [PiDxeS3BootScriptLib]  ||
  - Knows about boot script location by  <+|
synchronizing with the other library   |
instance via   |
PcdS3BootScriptTablePrivateDataPtr.|
  - Copies relocated image of itself to|
reserved memory. + |
  - Saved image contains pointer to boot script.  ---|--+  |
 |  |  |
Runtime: |  |  |
 |  |  |
(3) OS is booted, writes OS waking vector to FACS,   |  |  |
suspends machine |  |  |
 |  |  |
S3 Resume (PEI): |  |  |
 |  |  |
(4) PlatformPei sets S3 Boot Mode based on CMOS  |  |  |
 |  |  |
(5) DXE core is skipped and EFI_PEI_S3_RESUME2 is|  |  |
called as last step of PEI   |  |  |
 |  |  |
(6) S3Resume2Pei retrieves from SMRAM LockBox:   |  |  |
- ACPI S3 Context (path to FACS)  <--|--|--+
  |  |  |
  +--|--|--+
- Boot Script Executor Image  <--+  |  |
|  |
(7) BootScriptExecutorDxe   |  |
  S3BootScriptLib [PiDxeS3BootScriptLib]|  |
  - executes boot script  <-+  |
   |
(8) OS waking vector available from ACPI S3 Context / FACS  <--+
is called

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/Platform.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 261c36c..7f7e8bd 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -337,9 +337,12 @@ VOID
 BootModeInitialization (
   )
 {
-  EFI_STATUS Status;
+  EFI_BOOT_MODE BootMode;
+  EFI_STATUSStatus;
 
-  Status = PeiServicesSetBootMode (BOOT_WITH_FULL_CONFIGURATION);
+  BootMode = (CmosRead8 (0xF) == 0xFE) ? BOOT_ON_S3_RESUME :
+ BOOT_WITH_FULL_CONFIGURATION;
+  Status = PeiServicesSetBootMode (BootMode);
   ASSERT_EFI_ERROR (Status);
 
   Status = PeiServicesInstallPpi (mPpiBootMode);
-- 
1.8.3.1


--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 23/24] OvmfPkg: S3 Resume: preallocate PEI_S3_RESUME_STATE for S3Resume2Pei

[Laszlo Ersek]

We don't need this reservation / preallocation in order to save data from
suspend to resume. (The ZeroMem() is added to make this obvious.) It
rather acts as a placeholder after cold boot, to keep the OS away.

S3Resume2Pei needs a PEI_S3_RESUME_STATE object. The object cannot be on
the stack (because it is used across stack switching). It also can't be a
global variable (because S3Resume2Pei in general could run from flash).
S3Resume2Pei cannot allocate it dynamically either (because that could
trample OS data). Hence we must preallocate the object for S3Resume2Pei,
in a spot that the OS never touches.

The lower-level PeiServicesAllocatePages() function
[MdePkg/Library/PeiServicesLib] is called rather than the higher-level
AllocatePool() / AllocatePages() functions
[MdePkg/Library/PeiMemoryAllocationLib] because the latter wrappers don't
provide access to EfiACPIMemoryNVS.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
 OvmfPkg/PlatformPei/Platform.c  | 25 +
 2 files changed, 27 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 028a640..aebfa33 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -56,6 +56,7 @@
   PeimEntryPoint
   MtrrLib
   PcdLib
+  BaseMemoryLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvBase
@@ -70,6 +71,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState
 
 [Ppis]
   gEfiPeiMasterBootModePpiGuid
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 2616757..261c36c 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -35,9 +35,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 #include "Cmos.h"
@@ -401,6 +403,28 @@ ReserveEmuSmmArea (
 
 
 VOID
+ReservePeiS3ResumeState (
+  VOID
+  )
+{
+  UINTNNumPages;
+  EFI_STATUS   Status;
+  EFI_PHYSICAL_ADDRESS Address;
+
+  //
+  // The contents of this region doesn't have to survive reboot. Its location
+  // must though.
+  //
+  NumPages = EFI_SIZE_TO_PAGES (sizeof (PEI_S3_RESUME_STATE));
+  Status = PeiServicesAllocatePages (EfiACPIMemoryNVS, NumPages, &Address);
+  ASSERT_EFI_ERROR (Status);
+  ZeroMem ((VOID *)(UINTN) Address, NumPages * EFI_PAGE_SIZE);
+  PcdSet64 (PcdPeiS3ResumeState, Address);
+  DEBUG ((EFI_D_INFO, "preallocated PeiS3ResumeState at 0x%Lx\n", Address));
+}
+
+
+VOID
 DebugDumpCmos (
   VOID
   )
@@ -462,6 +486,7 @@ InitializePlatform (
 
   ReserveEmuVariableNvStore ();
   ReserveEmuSmmArea ();
+  ReservePeiS3ResumeState ();
 
   PeiFvInitialization ();
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 11/24] OvmfPkg: S3 Suspend: introduce DiscloseSmstSmm driver

[Laszlo Ersek]

This is a rogue SMM driver. It runs in SMM mode and has access to
confidential SMM data. It saves the address of the SMST for the next
patch, in runtime storage pointed-to by the PCD added in the previous
patch, and exits.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf | 51 +
 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c   | 38 +
 OvmfPkg/OvmfPkgX64.dsc  |  2 ++
 OvmfPkg/OvmfPkgX64.fdf  |  1 +
 4 files changed, 92 insertions(+)
 create mode 100644 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
 create mode 100644 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c

diff --git a/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf 
b/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
new file mode 100644
index 000..5ff895d
--- /dev/null
+++ b/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
@@ -0,0 +1,51 @@
+## @file
+# An SMM driver that publishes the address of the SMST.
+#
+# Copyright (C) 2013, 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  = DiscloseSmstSmm
+  FILE_GUID  = 2AD83D53-687B-4C3A-8840-EE71164195EB
+  MODULE_TYPE= DXE_SMM_DRIVER
+  VERSION_STRING = 1.0
+  PI_SPECIFICATION_VERSION   = 0x0001000A
+  ENTRY_POINT= DiscloseSmstSmmEntryPoint
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  DiscloseSmstSmm.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  DebugLib
+  PcdLib
+  SmmServicesTableLib
+  UefiDriverEntryPoint
+
+[Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdDiscloseSmstPtrPtr
+
+[Guids]
+
+[Protocols]
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c 
b/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c
new file mode 100644
index 000..152ff98
--- /dev/null
+++ b/OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c
@@ -0,0 +1,38 @@
+/** @file
+  An SMM driver that publishes the address of the SMST.
+
+  Copyright (C) 2013, 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.
+
+**/
+
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+DiscloseSmstSmmEntryPoint (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  UINT64 *DiscloseSmstPtrPtr;
+
+  DiscloseSmstPtrPtr = (UINT64 *)(UINTN) PcdGet64 (PcdDiscloseSmstPtrPtr);
+  ASSERT (DiscloseSmstPtrPtr != NULL);
+
+  *DiscloseSmstPtrPtr = (UINT64)(UINTN) gSmst;
+
+  //
+  // No need to keep this in memory after setting the PCD.
+  //
+  return EFI_ABORTED;
+}
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 7bcb19c..9775849 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -280,6 +280,7 @@
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
   LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
+  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
 
 

 #
@@ -523,6 +524,7 @@
   MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
   MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
   MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
+  OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
 
   #
   # ACPI Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 9e2da17..f7b903a 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -367,6 +367,7 @@ INF  OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
 INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 INF  MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
+INF  OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
 
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
h

[edk2] [RFC v2 07/24] OvmfPkg: S3 Suspend: save ACPI context

[Laszlo Ersek]

"OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" (originally:
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf")
produces the EFI_ACPI_S3_SAVE_PROTOCOL.

When found, this protocol is automatically invoked by
BdsLibBootViaBootOption(), in file
"IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c", right before
booting a boot option, to save ACPI S3 context.

At that point during BDS, our AcpiPlatformDxe driver will have installed
the FACS table (which AcpiS3SaveDxe has a use-time dependency upon).

With regard to dependencies: AcpiS3SaveDxe implements
EFI_ACPI_S3_SAVE_PROTOCOL by relying on LockBoxLib. Hence we must resolve
LockBoxLib for DXE_DRIVER module types too from now on.

  BdsLibBootViaBootOption()
EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
  LockBoxLib [SmmLockBoxDxeLib]
EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
gEfiSmmLockBoxCommunicationGuid [SmmLockBox]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]
  LockBoxLib [SmmLockBoxSmmLib]

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 2a8c625..c738cc7 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -248,6 +248,7 @@
   DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
   PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
 
 [LibraryClasses.common.UEFI_APPLICATION]
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
@@ -526,6 +527,7 @@
   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
   OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
   OvmfPkg/AcpiTables/AcpiTables.inf
+  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 4edefee..43d0e52 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -371,6 +371,7 @@ INF  
MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
+INF  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
 
 INF  RuleOverride = BINARY FatBinPkg/EnhancedFatDxe/Fat.inf
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 08/24] OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot Script

[Laszlo Ersek]

"MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces
the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3
Boot Script, to be replayed in PEI during S3 Resume. The script contains
opcodes and opcode arguments to configure CPU, PCI and IO resources.

S3SaveStateDxe relies on the S3BootScriptLib library. The Null
implementation is not useful for actually saving the boot script, we need
the PiDxeS3BootScriptLib instance.

The PiDxeS3BootScriptLib library instance depends on
EFI_SMM_BASE2_PROTOCOL and LockBoxLib, included in the previous patches.

PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null
instance of the latter. It means that SMBus commands in the boot script
will have no effect when interpreted during S3 Resume. This should be fine
for OvmfPkg and QEMU.

  EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
  EFI_SMM_BASE2_PROTOCOL [PiSmmCore]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
  SmbusLib [BaseSmbusLibNull]
  LockBoxLib [SmmLockBoxDxeLib]
EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
gEfiSmmLockBoxCommunicationGuid [SmmLockBox]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]
  LockBoxLib [SmmLockBoxSmmLib]

When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver
(purely as a form of notification), the S3SaveStateDxe driver saves the
boot script to SMRAM.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgX64.dsc | 4 
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 2 files changed, 5 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c738cc7..7bcb19c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -125,6 +125,9 @@
   
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
 !endif
 
+  
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
+  SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
+
 [LibraryClasses.common]
 !if $(SECURE_BOOT_ENABLE) == TRUE
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -528,6 +531,7 @@
   OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
   OvmfPkg/AcpiTables/AcpiTables.inf
   OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 43d0e52..9e2da17 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -372,6 +372,7 @@ INF  
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 
 INF  RuleOverride = BINARY FatBinPkg/EnhancedFatDxe/Fat.inf
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 01/24] OvmfPkg: PlatformPei: reserve RAM as SMRAM backing store

[Laszlo Ersek]

The same trick is used as for the original NvVars emulation; the
allocation is done early so that it ends up at an invariant address across
warm reboot.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
 OvmfPkg/PlatformPei/Platform.c  | 25 +
 OvmfPkg/OvmfPkg.dec | 11 +++
 3 files changed, 38 insertions(+)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index 7fe9d47..8811542 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -61,6 +61,8 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvSize
   gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase
   gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Platform.c
index 7363702..4bce240 100644
--- a/OvmfPkg/PlatformPei/Platform.c
+++ b/OvmfPkg/PlatformPei/Platform.c
@@ -373,6 +373,30 @@ ReserveEmuVariableNvStore (
 
 
 VOID
+ReserveEmuSmmArea (
+  VOID
+  )
+{
+  UINT32 AreaSize;
+  VOID   *Address;
+
+  AreaSize = PcdGet32 (PcdEmuSmmAreaSize);
+  if (AreaSize == 0) {
+return;
+  }
+
+  //
+  // We use the same trick here as in ReserveEmuVariableNvStore(). This area
+  // expressly doesn't need to survive cold reboots, only S3 Suspend and
+  // Resume.
+  //
+  Address = AllocateRuntimePool (AreaSize);
+  ASSERT (Address != NULL);
+  PcdSet64 (PcdEmuSmmAreaBase, (UINT64)(UINTN) Address);
+}
+
+
+VOID
 DebugDumpCmos (
   VOID
   )
@@ -433,6 +457,7 @@ InitializePlatform (
   }
 
   ReserveEmuVariableNvStore ();
+  ReserveEmuSmmArea ();
 
   PeiFvInitialization ();
 
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 9d7fedf..21105ad 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -69,6 +69,11 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
   gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
 
+  ## This PCD determines the size of the runtime pool allocation that we
+  #  reserve in PlatformPei as backing store for EmuSmmDxe (ie. SMRAM
+  #  emulation). Zero size disables SMRAM emulation.
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaSize|0x0010|UINT32|0x11
+
 [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UINT32|0x8
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT32|0x9
@@ -83,5 +88,11 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
 
+  ## The following PCD carries from PlatformPei to EmuSmmDxe the base address
+  #  of the runtime pool allocation that we reserve as backing store for SMRAM
+  #  emulation. Its type cannot be VOID* because PEI and DXE can have different
+  #  bitnesses.
+  gUefiOvmfPkgTokenSpaceGuid.PcdEmuSmmAreaBase|0x0|UINT64|0x12
+
 [PcdsFeatureFlag]
   gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable|FALSE|BOOLEAN|3
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 17/24] OvmfPkg: S3 Resume: reserve initial (pre-migr.) SEC/PEI stack and PEI heap

[Laszlo Ersek]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/Fv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/OvmfPkg/PlatformPei/Fv.c b/OvmfPkg/PlatformPei/Fv.c
index 4a31cc3..ab736f7 100644
--- a/OvmfPkg/PlatformPei/Fv.c
+++ b/OvmfPkg/PlatformPei/Fv.c
@@ -66,6 +66,16 @@ PeiFvInitialization (
 EfiACPIMemoryNVS
 );
 
+  //
+  // Cover the initial RAM area used as stack and temporary PEI heap. The base
+  // constant comes from OvmfPkg/Sec/{Ia32,X64}/SecEntry.{asm,S}, the size
+  // originates from SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c].
+  //
+  BuildMemoryAllocationHob (
+BASE_512KB - SIZE_64KB,
+SIZE_64KB,
+EfiACPIMemoryNVS
+);
   return EFI_SUCCESS;
 }
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 05/24] OvmfPkg: S3 Suspend: use SMM instances for LockBoxLib library class

[Laszlo Ersek]

LockBoxLib has two sets of implementations. The Null implementation (which
is the OVMF default) is not useful for us any longer; we need the library
instances that back the LockBox structure with SMRAM -- the SmmLockBoxLib
variants.

These variants (library instances) are for:
- DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER, UEFI_APPLICATION: usable
  from "untrusted", 3rd party drivers; communicates with the SmmLockBox
  driver (which is trusted and runs in SMM).
- PEIM: same purpose but for PEIMs.
- DXE_SMM_DRIVER: this is the low level driver that runs inside the
  trusted SmmLockBox driver, and manipulates SMRAM.

  LockBoxLib [SmmLockBoxDxeLib]
EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
gEfiSmmLockBoxCommunicationGuid [SmmLockBox]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]
  LockBoxLib [SmmLockBoxSmmLib]

In this patch, we resolve the library class only for DXE_RUNTIME_DRIVER
and DXE_SMM_DRIVER (which is sufficient to build and run OvmfPkg). We'll
add the other resolutions when we need them.

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 62a660d..2a8c625 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -104,7 +104,6 @@
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
   VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
   LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
-  LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
 !ifdef $(SOURCE_DEBUG_ENABLE)
@@ -217,6 +216,7 @@
 !if $(SECURE_BOOT_ENABLE) == TRUE
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
 !endif
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
@@ -275,6 +275,7 @@
 !else
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
 
 

 #
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 19/24] OvmfPkg: S3 Resume: ensure survival of migrated PEI stack / heap

[Laszlo Ersek]

OVMF's PlatformPei module discovers and installs permanent memory:

InitializePlatform [OvmfPkg/PlatformPei/Platform.c]
  PublishPeiMemory() for Xen | MemDetect() otherwise
PublishSystemMemory() [MdePkg/.../PeiResourcePublicationLib.c]
  PeiServicesInstallPeiMemory() [MdePkg/.../PeiServicesLib.c]
PeiInstallPeiMemory() [MdeModulePkg/Core/Pei/.../MemoryServices.c]

This enables PeiDispatcher()
[MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c] via the private
"SwitchStackSignal" flag to migrate the PEI phase's temporary stack and
heap to the permanent memory just discovered.

(OVMF implements said migration in TemporaryRamMigration()
[OvmfPkg/Sec/SecMain.c], exposed through the (optional)
EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI interface.)

The ever-current stack is exposed to the rest of the system through a
memory allocation HOB that is named with a special GUID. The PEI
dispatcher installs this HOB right before migrating the stack / heap from
temporary RAM to permanent RAM:

PeiDispatcher() [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]
  BuildStackHob() [MdePkg/Library/PeiHobLib/HobLib.c]
  TemporaryRamMigration() [OvmfPkg/Sec/SecMain.c]

Per default, BuildStackHob() describes the PEI stack/heap as
EfiBootServicesData. It makes sense because the PEI stack and heap are
usually not needed to survive into (or even after) runtime.

However, in OVMF we rewrite the area during S3 Resume (when we repeat the
same temporary RAM migration), hence we must prevent the OS from
repurposing it. Let's look up the HOB and flip the described memory type
to ACPI NVS in TemporaryRamMigration().

(Note that refreshing the preinstalled stack allocation HOB is permitted,
the DXE IPL does it too when not on the S3 resume path):

HandOffToDxeCore()
  UpdateStackHob()

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Sec/SecMain.inf |  4 
 OvmfPkg/Sec/SecMain.c   | 35 +++
 2 files changed, 39 insertions(+)

diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
index 91d0a44..d0f9455 100644
--- a/OvmfPkg/Sec/SecMain.inf
+++ b/OvmfPkg/Sec/SecMain.inf
@@ -59,6 +59,7 @@
   PeCoffGetEntryPointLib
   PeCoffExtraActionLib
   ExtractGuidedSectionLib
+  HobLib
 
 [Ppis]
   gEfiTemporaryRamSupportPpiGuid# PPI ALWAYS_PRODUCED
@@ -66,3 +67,6 @@
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvBase
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfMemFvSize
+
+[Guids]
+  gEfiHobMemoryAllocStackGuid
diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
index 3882dad..77aeffa 100644
--- a/OvmfPkg/Sec/SecMain.c
+++ b/OvmfPkg/Sec/SecMain.c
@@ -28,9 +28,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
+#include 
+
 #define SEC_IDT_ENTRY_COUNT  34
 
 typedef struct _SEC_IDT_TABLE {
@@ -695,6 +698,31 @@ SecStartupPhase2(
   CpuDeadLoop ();
 }
 
+/**
+  Expand the lifetime of the migrated PEI stack / heap area by changing its
+  allocation type to ACPI NVS.
+**/
+VOID
+EFIAPI
+ReservePermanentFromOs (
+  VOID
+  )
+{
+  EFI_HOB_MEMORY_ALLOCATION *MemHob;
+
+  for (MemHob = GetFirstHob (EFI_HOB_TYPE_MEMORY_ALLOCATION); MemHob != NULL;
+   MemHob = GetNextHob (EFI_HOB_TYPE_MEMORY_ALLOCATION,
+GET_NEXT_HOB (MemHob))) {
+if (CompareGuid (&gEfiHobMemoryAllocStackGuid,
+  &MemHob->AllocDescriptor.Name)) {
+  break;
+}
+  }
+  ASSERT (MemHob != NULL);
+  ASSERT (MemHob->AllocDescriptor.MemoryType == EfiBootServicesData);
+  MemHob->AllocDescriptor.MemoryType = EfiACPIMemoryNVS;
+}
+
 EFI_STATUS
 EFIAPI
 TemporaryRamMigration (
@@ -715,6 +743,13 @@ TemporaryRamMigration (
   
   DEBUG ((EFI_D_ERROR, "TemporaryRamMigration(0x%x, 0x%x, 0x%x)\n", 
(UINTN)TemporaryMemoryBase, (UINTN)PermanentMemoryBase, CopySize));
   
+  //
+  // This pokes into a HOB that's currently in temporary memory itself. Update
+  // it before it is migrated to permanent memory, with the rest of temporary
+  // memory.
+  //
+  ReservePermanentFromOs ();
+
   OldHeap = (VOID*)(UINTN)TemporaryMemoryBase;
   NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
   
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 14/24] OvmfPkg: S3 Resume: pull in PEIM orchestrating S3 Resume

[Laszlo Ersek]

"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf" produces the
EFI_PEI_S3_RESUME2 PEIM-to-PEIM Interface.

When the platform-specific initialization code (in PEI) sets the Boot Mode
to BOOT_ON_S3_RESUME, the DXE IPL (which is the last step in PEI) skips
the DXE phase entirely, and executes the S3 Resume PEIM through the
EFI_PEI_S3_RESUME2 interface instead. (See DxeLoadCore() in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c".)

S3Resume2Pei depends on LockBoxLib (the non-Null PEIM implementation), and
also a PEI-phase driver to access SMRAM.

  EFI_PEI_S3_RESUME2 [S3Resume2Pei]
LockBoxLib [SmmLockBoxPeiLib]
  EFI_PEI_SMM_COMMUNICATION_PPI [EmuSmmPei]
  PEI_SMM_ACCESS_PPI [EmuSmmPei]
PEI_SMM_ACCESS_PPI [EmuSmmPei]
GuidHob(gEfiAcpiVariableGuid) [EmuSmmPei]

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e375ae3..a2e3f13 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -186,6 +186,7 @@
 !ifdef $(SOURCE_DEBUG_ENABLE)
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
 !endif
+  LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
 
 [LibraryClasses.common.DXE_CORE]
   HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
@@ -409,6 +410,10 @@
 
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   }
+  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
+
+  PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
+  }
 
   #
   # DXE Phase modules
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index f7ebe82..e435486 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -259,6 +259,7 @@ INF  
IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf
 INF  OvmfPkg/PlatformPei/PlatformPei.inf
 INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  OvmfPkg/EmuSmmPei/EmuSmmPei.inf
+INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
 
 FILE FV_IMAGE = A4EF5A93-3F1B-4232-A1C4-F0910E6D1D9C {
   SECTION COMPRESS PI_NONE {
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 20/24] OvmfPkg: S3 Resume: flatten DXEFV into MAINFV

[Laszlo Ersek]

The PEI dispatcher handles PEIMs and embedded firmware volume images.
PEIMs are loaded and called (1), while embedded firmware volume images are
recursively scanned (2) for PEIMs and for further embedded firmware volume
images. FirmwareVolmeInfoPpiNotifyCallback() is the function directly
producing the newly detected entries for the dispatcher.

PeiDispatcher() [MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c]
(3)   DepexSatisfied()
(4) PeiServicesFfsFindSectionData(DEPEX) [MdePkg/.../PeiServicesLib.c]
  PeiFfsFindSectionData() [MdeModulePkg/Core/Pei/FwVol/FwVol.c]
PeiFfsFvPpiFindSectionByType()
  PeiFfsFvPpiFindSectionByType2()
ProcessSection()
(5)   Decompress() [MdeModulePkg/Core/DxeIplPeim/DxeLoad.c]
AllocatePages() [MdePkg/.../PeiMemoryAllocationLib]
  if satisfied:
PeiFfsFvPpiGetFileInfo() [MdeModulePkg/Core/Pei/FwVol/FwVol.c]
if EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE:
(2)   ProcessFvFile()
PeiServicesInstallFvInfo2Ppi() [MdePkg/.../PeiServicesLib]
  InternalPeiServicesInstallFvInfoPpi()
PeiServicesInstallPpi()
  FirmwareVolmeInfoPpiNotifyCallback() [.../FwVol.c]
ProcessFvFile()
  ...
else:
(1)   PeiLoadImage()

PeiDispatcher checks for dependency expressions first (3),  and the
type-dependent processing in (1) and (2) happens only if such a Depex is
satisfied (or absent).

Files of type EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE can have no Depex
sections, they are pure containers. DepexSatisfied() at (3) always returns
TRUE for them, so functionality is not directly harmed.

However, an EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE can be compressed. In
order to look up the (nonexistent) Depex section (4), the Decompress
routine (5) is called.

Unfortunately, the Decompress() routine allocates EfiBootServicesData
memory. This is not permitted on the S3 Resume path, but PeiDispatcher()
is part of the S3 Resume path.

The problem is triggered by OVMF's firmware structure:

  FD.OVMF
FV.FVMAIN_COMPACT uncompressed
  FV.MAINFV   compressed with LzmaCompress
individual PEI modulesuncompressed
FV.DXEFV  compressed with PI_NONE
  individual DXE modules  uncompressed
FV.SECFV  uncompressed

FV.MAINFV is decompressed by OVMF's SEC and is only exposed to the PEI
dispatcher in decompressed form, so that's not the problem. However
FV.DXEFV, which is a direct sibling of the PEIMs, is compressed (with the
PI_NONE === EFI_NOT_COMPRESSED compression subtype). This causes an
invalid EfiBootServicesData allocation during S3 Resume, inside the
useless Depex check.

Avoiding the allocation by restricting the Depex check in PeiDispatcher()
to PEIMs doesn't help: ProcessFvFile() under (2) triggers the same
allocation by calling PeiFfsFvPpiFindSectionByType2() -- it must
decompress the file in order to scan it.

Changing FV.DXEFV's encapsulation from COMPRESS to GUIDED won't help
either, because in that case ProcessSection() would want to call
EFI_PEI_GUIDED_SECTION_EXTRACTION_PPI.ExtractSection(), which again
allocates memory.

Solve this by flattening FV.MAINFV:

  FD.OVMF
FV.FVMAIN_COMPACT uncompressed
  FV.MAINFV   compressed with LzmaCompress
individual PEI modulesuncompressed
individual DXE modulesuncompressed
FV.SECFV  uncompressed

This way we avoid recursive processing, without hurting the efficiency of
the outermost compression (in FV.MAINFV).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgX64.fdf | 39 ++-
 1 file changed, 6 insertions(+), 33 deletions(-)

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index e435486..2508c22 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -250,6 +250,12 @@ APRIORI PEI {
   INF  MdeModulePkg/Universal/PCD/Pei/Pcd.inf
 }
 
+APRIORI DXE {
+  INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
+  INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
+  INF  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
+}
+
 #
 #  PEI Phase modules
 #
@@ -261,39 +267,6 @@ INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  OvmfPkg/EmuSmmPei/EmuSmmPei.inf
 INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
 
-FILE FV_IMAGE = A4EF5A93-3F1B-4232-A1C4-F0910E6D1D9C {
-  SECTION COMPRESS PI_NONE {
-SECTION FV_IMAGE = DXEFV
-  }
-}
-
-
-
-[FV.DXEFV]
-BlockSize  = 0x1
-FvAlignment= 16
-ERASE_POLARITY = 1
-MEMORY_MAPPED  = TRUE
-STICKY_WRITE   = TRUE
-LOCK_CAP   = TRUE
-LOCK_STATUS= TRUE
-WRITE_DISABLED_CAP = TRUE
-WRITE_ENABLED_CAP  = TRUE

[edk2] [RFC v2 03/24] OvmfPkg: S3 Suspend: pull in DXE driver for EFI_SMM_COMMUNICATION_PROTOCOL

[Laszlo Ersek]

The low-level data transfer between S3 Suspend and S3 Resume happens thru
SMRAM. SMRAM is theoretically accessible to SMM drivers only; other
("untrusted") drivers can only talk to the former via
EFI_SMM_COMMUNICATION_PROTOCOL.

"MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" implements the SMM Initial
Program Loader. It produces EFI_SMM_BASE2_PROTOCOL and
EFI_SMM_COMMUNICATION_PROTOCOL, relying on the previous patch:

  EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]

  EFI_SMM_BASE2_PROTOCOL [PiSmmCore]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]

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

The SMM Core introduces further DSC dependencies:
- library classes that are specific to it (SmmCorePlatformHookLib),
- library instances that are specific to it
  (PiSmmCoreMemoryAllocationLib),
- the ReportStatusCodeLib dependency can be resolved by the already used
  DxeReportStatusCodeLib (it serves SMM_CORE as well)
- DebugLib simply needs to be resolved (both serial and qemu debug port
  implementations are BASE)

...and FDF / Rule dependencies:
- we introduce an SMM_CORE rule that imitates DXE_CORE (since the contents
  is a core binary that will be executed after relocation)

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index cef5113..351ec73 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -258,6 +258,16 @@
   DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
 !endif
 
+[LibraryClasses.common.SMM_CORE]
+  
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
+  
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+!ifdef $(DEBUG_ON_SERIAL_PORT)
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!else
+  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
+!endif
+
 

 #
 # Pcd Section - list of all EDK II PCD Entries defined by this Platform.
@@ -497,6 +507,8 @@
   # SMM Support
   #
   OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
+  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 
   #
   # ACPI Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 42294e8..34cf4ed 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -364,6 +364,8 @@ INF  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
 INF  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 
 INF  OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
+INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
+INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
 
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -539,3 +541,10 @@ FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
   FILE RAW = $(NAMED_GUID) {
 RAW RAW|.raw
   }
+
+[Rule.Common.SMM_CORE]
+  FILE SMM_CORE = $(NAMED_GUID) {
+PE32 PE32   $(INF_OUTPUT)/$(MODULE_NAME).efi
+UI   STRING="$(MODULE_NAME)" Optional
+VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
+  }
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 21/24] UefiCpuPkg: S3Resume2Pei: align return stacks explicitly

[Laszlo Ersek]

S3RestoreConfig2() can optionally stack-switch to the SMM S3 Resume Entry
Point and ask it to transfer to S3ResumeExecuteBootScript().

Similarly, S3ResumeExecuteBootScript() stack-switches explicitly to the
boot script executor, and asks it to transfer to S3ResumeBootOs().

Currently the stack pointers specified for the SMM S3 Resume Entry Point
and the boot script executor to use for returning are derived from
addresses of the first local variables in S3RestoreConfig2() and
S3ResumeExecuteBootScript(), respectively.

Since (theoretically) the stack grows down as local variables are defined
and functions are called, the idea is presumably to allow the respective
callee to overwrite the caller's local variables. (The callees in question
can never return normally, only by explicit stack switching.)

Taking the address of "Status" is less portable than optimal however.
Compilers are free to juggle local variables at build time as they please,
including order and alignment on the stack. For example, when the code is
built for 64-bit PEI with gcc-4.8.2, the address of "Status" trips up the
alignment assertion in SwitchStack().

Let's align the address of "Status" down to CPU_STACK_ALIGNMENT
explicitly. If a compiler ensures such alignment and places "Status" at
the highest address automatically, then this change has no effect.
Otherwise, we'll prepare ReturnStackPointer values that (a) are correctly
aligned, (b) preserve the same amount or more (but never less) from the
caller's local variables than before, which should be safe.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index e57398b..426eef7 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -733,6 +733,16 @@ RestoreS3PageTables (
 }
 
 /**
+  This macro aligns the address of a variable with auto storage duration down
+  to CPU_STACK_ALIGNMENT.
+
+  Since the stack grows downward, the result preserves more of the stack than
+  the original address (or the same amount), not less.
+**/
+#define STACK_ALIGN_DOWN(Ptr) \
+  ((UINTN)(Ptr) & ~(UINTN)(CPU_STACK_ALIGNMENT - 1))
+
+/**
   Jump to boot script executor driver.
 
   The function will close and lock SMRAM and then jump to boot script execute 
driver to executing S3 boot script table.
@@ -846,7 +856,7 @@ S3ResumeExecuteBootScript (
   DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
   PeiS3ResumeState->ReturnEntryPoint   = 
(EFI_PHYSICAL_ADDRESS)(UINTN)S3ResumeBootOs;
-  PeiS3ResumeState->ReturnStackPointer = (EFI_PHYSICAL_ADDRESS)(UINTN)&Status;
+  PeiS3ResumeState->ReturnStackPointer = 
(EFI_PHYSICAL_ADDRESS)STACK_ALIGN_DOWN (&Status);
   //
   // Save IDT
   //
@@ -1038,7 +1048,7 @@ S3RestoreConfig2 (
 SmmS3ResumeState->ReturnEntryPoint   = 
(EFI_PHYSICAL_ADDRESS)(UINTN)S3ResumeExecuteBootScript;
 SmmS3ResumeState->ReturnContext1 = 
(EFI_PHYSICAL_ADDRESS)(UINTN)AcpiS3Context;
 SmmS3ResumeState->ReturnContext2 = 
(EFI_PHYSICAL_ADDRESS)(UINTN)EfiBootScriptExecutorVariable;
-SmmS3ResumeState->ReturnStackPointer = 
(EFI_PHYSICAL_ADDRESS)(UINTN)&Status;
+SmmS3ResumeState->ReturnStackPointer = 
(EFI_PHYSICAL_ADDRESS)STACK_ALIGN_DOWN (&Status);
 
 DEBUG (( EFI_D_ERROR, "SMM S3 Signature= %x\n", 
SmmS3ResumeState->Signature));
 DEBUG (( EFI_D_ERROR, "SMM S3 Stack Base   = %x\n", 
SmmS3ResumeState->SmmS3StackBase));
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 22/24] UefiCpuPkg: S3Resume2Pei: allow preallocation of PEI_S3_RESUME_STATE

[Laszlo Ersek]

This patch enables S3Resume2Pei to eliminate an could be invalid during S3
Resume.

The concrete implementation allocates memory from the HOB heap:

S3ResumeExecuteBootScript() [UefiCpuPkg/.../S3Resume2Pei/S3Resume.c]
  AllocatePool() [MdePkg/Library/PeiMemoryAllocationLib]
PeiServicesAllocatePool() [MdePkg/Library/PeiServicesLib]
  PeiAllocatePool() [MdeModulePkg/Core/Pei/Memory/MemoryServices.c]
PeiServicesCreateHob(EFI_HOB_TYPE_MEMORY_POOL)

but we might already be past the migration from temporary RAM to permanent
RAM. In that case the new allocation will fall outside of the permanent
RAM area that may have been reserved from the OS, for example as ACPI NVS
memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf | 1 +
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c   | 5 -
 UefiCpuPkg/UefiCpuPkg.dec   | 7 +++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
index db5d66e..85d6d3d 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
@@ -85,6 +85,7 @@
 
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState
 
 [Depex]
   TRUE
diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
index 426eef7..c5a3b66 100644
--- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
+++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
@@ -851,7 +851,10 @@ S3ResumeExecuteBootScript (
   //
   // Prepare data for return back
   //
-  PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));
+  PeiS3ResumeState = (VOID *)(UINTN)PcdGet64 (PcdPeiS3ResumeState);
+  if (PeiS3ResumeState == NULL) {
+PeiS3ResumeState = AllocatePool (sizeof(*PeiS3ResumeState));
+  }
   ASSERT (PeiS3ResumeState != NULL);
   DEBUG (( EFI_D_ERROR, "PeiS3ResumeState - %x\r\n", PeiS3ResumeState));
   PeiS3ResumeState->ReturnCs   = 0x10;
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index b3858b1..d962ef6 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -44,3 +44,10 @@
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress|0xfee0|UINT32|0x0001
 
+[PcdsDynamic, PcdsDynamicEx]
+  ## The following PCD controls the allocation of "PeiS3ResumeState" in
+  #  S3ResumeExecuteBootScript()
+  #  [UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c]. When left at NULL,
+  #  "PeiS3ResumeState" will be allocated with AllocatePool(). Otherwise the
+  #  address specified in the PCD will be assigned to "PeiS3ResumeState".
+  gUefiCpuPkgTokenSpaceGuid.PcdPeiS3ResumeState|0x0|UINT64|0x0002
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 13/24] OvmfPkg: S3 Resume: pull in BootScriptExecutorDxe

[Laszlo Ersek]

This driver (from
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf")
is first loaded normally during DXE. When the
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely
as a form of notification), the driver reloads itself to reserved memory.

During S3 Resume / PEI, the driver image is executed from there. In order
to access the boot script saved during S3 Suspend, LockBox access is
needed.

The boot script is transferred internal to PiDxeS3BootScriptLib:

Both S3SaveStateDxe and BootScriptExecutorDxe are statically linked
against PiDxeS3BootScriptLib. Whichever is loaded first (during normal
boot, in the DXE phase), allocates the root storage for the script. The
address is then passed between the PiDxeS3BootScriptLib instances living
in the two separate drivers thru the dynamic
PcdS3BootScriptTablePrivateDataPtr PCD.

Dependencies:

  BootScriptExecutorDxe
gEfiLockBoxProtocolGuid [SmmLockBox]
S3BootScriptLib [PiDxeS3BootScriptLib]
  EFI_SMM_BASE2_PROTOCOL [PiSmmCore]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
  SmbusLib [BaseSmbusLibNull]
  LockBoxLib [SmmLockBoxDxeLib]
EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
gEfiSmmLockBoxCommunicationGuid [SmmLockBox]
  EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
  gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]
  LockBoxLib [SmmLockBoxSmmLib]
LockBoxLib [SmmLockBoxDxeLib]
  EFI_SMM_COMMUNICATION_PROTOCOL [PiSmmCore]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
EFI_SMM_CONTROL2_PROTOCOL [EmuSmmDxe]
  gEfiSmmLockBoxCommunicationGuid [SmmLockBox]
EFI_SMM_ACCESS2_PROTOCOL [EmuSmmDxe]
gEfiSmmSwDispatch2ProtocolGuid [unneeded / EmuSmmDxe]
LockBoxLib [SmmLockBoxSmmLib]

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

diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c8cc68d..e375ae3 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -538,6 +538,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
+  MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 7a80330..f7ebe82 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -375,6 +375,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
 
 INF  RuleOverride = BINARY FatBinPkg/EnhancedFatDxe/Fat.inf
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC v2 06/24] OvmfPkg: S3 Suspend: import specialized copy of AcpiS3SaveDxe

[Laszlo Ersek]

"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf"
currently specifies a DepEx on gEfiMpServiceProtocolGuid (MP Services).

The justification is the following code sequence:

  InstallAcpiS3Save()
if PcdFrameworkCompatibilitySupport is set:
  InstallAcpiS3SaveThunk()
if EFI_MP_SERVICES_PROTOCOL is available:
  GetVariable(ACPI_GLOBAL_VARIABLE)

In English, the AcpiS3SaveDxe driver insists on the presence of MP
Services *unconditionally* because,

- if PcdFrameworkCompatibilitySupport is set (the default is false),
- and MP Services are available (which is constant true under the above
  condition),

then the AcpiS3SaveDxe driver would like to get the ACPI_GLOBAL_VARIABLE
variable from the MP Services driver, rather than setting it itself.

The DepEx prevents AcpiS3SaveDxe from loading under OvmfPkg, since we
provide no MP Services implementation. This is particularly broken since
the default PcdFrameworkCompatibilitySupport value is FALSE, making the
entire code that would look at EFI_MP_SERVICES_PROTOCOL dead.

Copy AcpiS3SaveDxe to OvmfPkg, substitute PcdFrameworkCompatibilitySupport
with constant FALSE, and remove all code that becomes dead, including the
DepEx.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  76 +
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h  |  59 
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 556 
 3 files changed, 691 insertions(+)
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
new file mode 100644
index 000..169e400
--- /dev/null
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -0,0 +1,76 @@
+## @file
+# Component description file for AcpiS3Save module.
+#
+# This is an implementation of the ACPI S3 Save protocol.
+# Copyright (c) 2006 - 2011, 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  = AcpiS3SaveDxe
+  FILE_GUID  = 6B79BBC0-26B9-4FE9-B631-551D8AB078C6
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= InstallAcpiS3Save
+
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64
+#
+
+[Sources]
+  AcpiS3Save.h
+  AcpiS3Save.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  IntelFrameworkPkg/IntelFrameworkPkg.dec
+  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
+
+[LibraryClasses]
+  PcdLib
+  UefiRuntimeServicesTableLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+  BaseMemoryLib
+  HobLib
+  UefiLib
+  LockBoxLib
+  DebugLib
+  DxeServicesLib
+
+[Guids]
+  gEfiAcpiVariableGuid  # ALWAYS_CONSUMED
+  gEfiAcpiS3ContextGuid # ALWAYS_CONSUMED
+  gEfiAcpi20TableGuid   # ALWAYS_CONSUMED  System Table
+  gEfiAcpi10TableGuid   # ALWAYS_CONSUMED  System Table
+
+[Protocols]
+  gEfiAcpiS3SaveProtocolGuid# PROTOCOL ALWAYS_PRODUCED
+  gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
+  gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
+  gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
+
+[FeaturePcd]
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformCsmSupport  ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
+
+[Pcd]
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize## 
CONSUMES
+  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3BootScriptStackSize   ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
+
+[Depex]
+  gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
new file mode 100644
index 000..65974a3
--- /dev/null
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
@@ -0,0 +1,59 @@
+/** @file
+  This is an implementation of the ACPI S3 Save protocol.  This is defined in 
+  S3 boot path specification 0.9.
+
+Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
+
+This program and the accompanying materials

[edk2] [RFC v2 09/24] OvmfPkg: S3 Suspend: save boot script after ACPI context

[Laszlo Ersek]

The trigger to actually save the boot script is the installation of
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL, to be performed by any DXE driver.
Installation of the protocol also locks down SMM (as its name indicates)
and prevents further LockBox access.

We cannot install this protocol before BdsLibBootViaBootOption() is called
(eg. in OVMF's PlatformBdsPolicyBehavior()), because
BdsLibBootViaBootOption() calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(), which
needs LockBox access.

We also can't install the protocol after BdsLibBootViaBootOption()
returns, simply because control is never returned to us.

Therefore modify our EFI_ACPI_S3_SAVE_PROTOCOL implementation so that the
boot script is prepared and installed internally to S3Save().

(The boot script must contain at least one opcode, otherwise
S3BootScriptLib runs into an assertion failure. We add a harmless (no-op)
"information" opcode.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  4 ++-
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 49 +
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
index 169e400..159cdb8 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
@@ -62,6 +62,8 @@
   gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
   gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
   gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
+  gEfiS3SaveStateProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
+  gEfiDxeSmmReadyToLockProtocolGuid # PROTOCOL ALWAYS_CONSUMED
 
 [FeaturePcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformCsmSupport  ## 
CONSUMES
@@ -73,4 +75,4 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
 
 [Depex]
-  gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
+  gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid AND 
gEfiS3SaveStateProtocolGuid
diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
index 80f12eb..684ddb7 100644
--- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
+++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
@@ -28,6 +28,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "AcpiS3Save.h"
@@ -407,6 +409,48 @@ LegacyGetS3MemorySize (
 }
 
 /**
+  Save the S3 boot script.
+
+  Note that we trigger DxeSmmReadyToLock here -- otherwise the script wouldn't
+  be saved actually. Triggering this protocol installation event in turn locks
+  down SMM, so no further changes to LockBoxes or SMRAM are possible
+  afterwards.
+**/
+STATIC
+VOID
+EFIAPI
+SaveS3BootScript (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EFI_S3_SAVE_STATE_PROTOCOL *BootScript;
+  EFI_HANDLE Handle;
+  STATIC CONST UINT8 Info[] = { 0xDE, 0xAD, 0xBE, 0xEF };
+
+  Status = gBS->LocateProtocol (&gEfiS3SaveStateProtocolGuid, NULL,
+  (VOID **) &BootScript);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Despite the opcode documentation in the PI spec, the protocol
+  // implementation embeds a deep copy of the info in the boot script, rather
+  // than storing just a pointer to runtime or NVS storage.
+  //
+  Status = BootScript->Write(BootScript, EFI_BOOT_SCRIPT_INFORMATION_OPCODE,
+ (UINT32) sizeof Info,
+ (EFI_PHYSICAL_ADDRESS)(UINTN) &Info);
+  ASSERT_EFI_ERROR (Status);
+
+  Handle = NULL;
+  Status = gBS->InstallProtocolInterface (&Handle,
+  &gEfiDxeSmmReadyToLockProtocolGuid, EFI_NATIVE_INTERFACE,
+  NULL);
+  ASSERT_EFI_ERROR (Status);
+}
+
+
+/**
   Prepares all information that is needed in the S3 resume boot path.
   
   Allocate the resources or prepare informations and save in ACPI variable set 
for S3 resume boot path  
@@ -511,6 +555,11 @@ S3Ready (
   Status = SetLockBoxAttributes (&gEfiAcpiS3ContextGuid, 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE);
   ASSERT_EFI_ERROR (Status);
 
+  //
+  // Save the boot script too. Note that this requires/includes emitting the
+  // DxeSmmReadyToLock event, which in turn locks down SMM.
+  //
+  SaveS3BootScript ();
   return EFI_SUCCESS;
 }
 
-- 
1.8.3.1



--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] uUEFI code execution

[Andrew Fish]

On Dec 8, 2013, at 8:05 PM, parmeshwr_pra...@dell.com wrote:

> Hi All,
>  
> How to get UEFI scheduling information ?

There is not a scheduler, there is just an event queue. 

If you look in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Event/Timer.c,
 CoreTimerTick() is called on the timer tick. You can see it get registered in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c
 

The event queues are generally processed on gBS->RestoreTpl(). See 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c

/**
  Lowers the task priority to the previous value.   If the new
  priority unmasks events at a higher priority, they are dispatched.

  @param  NewTpl  New, lower, task priority

**/
VOID
EFIAPI
CoreRestoreTpl (
  IN EFI_TPL NewTpl
  )
{
  EFI_TPL OldTpl;

  OldTpl = gEfiCurrentTpl;
  ASSERT (NewTpl <= OldTpl);
  ASSERT (VALID_TPL (NewTpl));

  //
  // If lowering below HIGH_LEVEL, make sure
  // interrupts are enabled
  //

  if (OldTpl >= TPL_HIGH_LEVEL  &&  NewTpl < TPL_HIGH_LEVEL) {
gEfiCurrentTpl = TPL_HIGH_LEVEL;
  }

  //
  // Dispatch any pending events
  //
  while (((-2 << NewTpl) & gEventPending) != 0) {
gEfiCurrentTpl = (UINTN) HighBitSet64 (gEventPending);
if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
  CoreSetInterruptState (TRUE);
}
CoreDispatchEventNotifies (gEfiCurrentTpl);
  }

  //
  // Set the new value
  //

  gEfiCurrentTpl = NewTpl;

  //
  // If lowering below HIGH_LEVEL, make sure
  // interrupts are enabled
  //
  if (gEfiCurrentTpl < TPL_HIGH_LEVEL) {
CoreSetInterruptState (TRUE);
  }

}


> Is this single or multi-threaded environment ?

EFI is really an event model. I’ve found this presentation to be helpful in 
explaining the difference between a thread model and an event model: 
http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf


Thanks,

Andrew Fish--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] uUEFI code execution

[Tim Lewis]

Technically, UEFI is two-threaded (main and timer). Most implementations have 
exactly one stack frame. What appears to be priority levels actually amounts to 
a prioritized list of registered callback functions. Resource sharing either 
involves using events or interrupt-masking, but since there are only two 
threads, these are limited.

Tim

From: parmeshwr_pra...@dell.com [mailto:parmeshwr_pra...@dell.com]
Sent: Sunday, December 08, 2013 10:06 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] uUEFI code execution


Hi All,

How to get UEFI scheduling information ?
Is this single or multi-threaded environment ?


Best Regards,
Parmeshwr Prasad
Tel : +91-9743262018
[cid:image002.png@01CE781A.38F61FE0]

<>--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ShellPkg: Remove invalid ASSERT

[Bjorge, Erik C]

Since the code exists to handle the error I think the change is good.

Reviewed-by: Erik Bjorge 

From: Carsey, Jaben
Sent: Monday, December 09, 2013 2:59 PM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Remove invalid ASSERT

Erik

Can you check this?

ShellPkg: Remove invalid ASSERT

There was an assumption that this API would never fail.  That is not true and 
the return value is checked just a few lines later.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] ShellPkg: Remove invalid ASSERT

[Carsey, Jaben]

Erik

Can you check this?

ShellPkg: Remove invalid ASSERT

There was an assumption that this API would never fail.  That is not true and 
the return value is checked just a few lines later.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 


Rm.c.patch
Description: Rm.c.patch
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ShellPkg: Add support for CTRL-C within shell user prompting

[Bjorge, Erik C]

The change looks good.

Reviewed-by: Erik Bjorge 


From: Carsey, Jaben
Sent: Monday, December 09, 2013 2:53 PM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Add support for CTRL-C within shell user prompting

Erik,

Can you review?


ShellPkg: Add support for CTRL-C within shell user prompting

This allows for the user to get out of answering a question with CTRL-C

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 
mailto:jaben.car...@intel.com>>
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] ShellPkg: Add support for CTRL-C within shell user prompting

[Carsey, Jaben]

Erik,

Can you review?


ShellPkg: Add support for CTRL-C within shell user prompting

This allows for the user to get out of answering a question with CTRL-C

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey 


ctrl-c_support_prompts.patch
Description: ctrl-c_support_prompts.patch
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] GUID for Flattened Device Tree in configuration table.

[Leif Lindholm]

Hi Tim,

Thank you for the explanation, and point taken. I'll keep this in mind.

However, this is not a name we're mandating (Grant simply grabbed a
line out of my source files to get the GUID) - we simply go with what
the existing code in Linux/GRUB forces us to conform with.
In the GRUB case, this means GRUB_EFI_ gets prepended to _all_ UEFI GUIDs.
In Linux, actually, we don't need the EFI_ bit, so will make sure to
leave it out.

/
Leif

On 9 December 2013 18:23, Tim Lewis  wrote:
> The reason that Liming mentions this is that we've had some bad experiences 
> with namespace collision for the #defines associated with GUIDs. For example, 
> Intel's Framework specifications used this, so when the PI specification 
> tried to use a name for similar functionality, it could not (which is why you 
> see "2" appended to protocol names when there was never a "1"). Some other 
> groups (including, for example, TCG) have decided that they would like to use 
> EFI_ as a namespace for their specific context.  And Intel has made some 
> slips in this area within the UEFI universe, esp. in the EDK2 implementation.
>
> Consider the case where the UEFI specification might want to implement some 
> UEFI device tree protocol or GUID. The name EFI_DEVICE_TREE_GUID defined 
> implies that it is an EFI device tree, when, in fact, it is merely produced 
> by an EFI component. I would suggest (at least) further qualifying the name 
> to make it clear which agent in the ecosystem "owns" the definition of the 
> device tree.
>
> Tim
>
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, December 09, 2013 9:41 AM
> To: Gao, Liming
> Cc: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] GUID for Flattened Device Tree in configuration table.
>
> Thank you.
>
> The code below is taken from the GRUB or Linux efi.h header, and as
> such prepends "EFI_" for namespace reasons.
>
> /
> Leif
>
> On Mon, Dec 09, 2013 at 02:18:20PM +, Gao, Liming wrote:
>> Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec. 
>> So, I suggest to remove prefix EFI_.
>>
>> -Original Message-
>> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
>> Sent: Monday, December 9, 2013 8:45 PM
>> To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz
>> Subject: [edk2] GUID for Flattened Device Tree in configuration table.
>>
>> Hi all,
>>
>> We (Linaro) are working on support for passing a flattened device tree
>> (FDT) via the UEFI configuration table. Before we publish patches, I want to 
>> make sure that we've generated a valid UUID for the FDT entry.
>> We used the Linux tool uuidgen and it produced this:
>>
>> #define EFI_DEVICE_TREE_GUID \
>>   { \
>> 0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
>> 0xe0 } \
>>   }
>>
>> I'm asking here to make sure we haven't made a fundamental error that gets 
>> implemented by some firmware. Have we done the right thing?
>>
>> g.
>>
>> --
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] GUID for Flattened Device Tree in configuration table.

[Tim Lewis]

Leif --

The reason that Liming mentions this is that we've had some bad experiences 
with namespace collision for the #defines associated with GUIDs. For example, 
Intel's Framework specifications used this, so when the PI specification tried 
to use a name for similar functionality, it could not (which is why you see "2" 
appended to protocol names when there was never a "1"). Some other groups 
(including, for example, TCG) have decided that they would like to use EFI_ as 
a namespace for their specific context.  And Intel has made some slips in this 
area within the UEFI universe, esp. in the EDK2 implementation.

Consider the case where the UEFI specification might want to implement some 
UEFI device tree protocol or GUID. The name EFI_DEVICE_TREE_GUID defined 
implies that it is an EFI device tree, when, in fact, it is merely produced by 
an EFI component. I would suggest (at least) further qualifying the name to 
make it clear which agent in the ecosystem "owns" the definition of the device 
tree.

Tim

-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Monday, December 09, 2013 9:41 AM
To: Gao, Liming
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] GUID for Flattened Device Tree in configuration table.

Thank you.

The code below is taken from the GRUB or Linux efi.h header, and as
such prepends "EFI_" for namespace reasons.

/
Leif

On Mon, Dec 09, 2013 at 02:18:20PM +, Gao, Liming wrote:
> Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec. 
> So, I suggest to remove prefix EFI_. 
> 
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca] 
> Sent: Monday, December 9, 2013 8:45 PM
> To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz
> Subject: [edk2] GUID for Flattened Device Tree in configuration table.
> 
> Hi all,
> 
> We (Linaro) are working on support for passing a flattened device tree
> (FDT) via the UEFI configuration table. Before we publish patches, I want to 
> make sure that we've generated a valid UUID for the FDT entry.
> We used the Linux tool uuidgen and it produced this:
> 
> #define EFI_DEVICE_TREE_GUID \
>   { \
> 0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> 0xe0 } \
>   }
> 
> I'm asking here to make sure we haven't made a fundamental error that gets 
> implemented by some firmware. Have we done the right thing?
> 
> g.
> 
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] GUID for Flattened Device Tree in configuration table.

[Leif Lindholm]

Thank you.

The code below is taken from the GRUB or Linux efi.h header, and as
such prepends "EFI_" for namespace reasons.

/
Leif

On Mon, Dec 09, 2013 at 02:18:20PM +, Gao, Liming wrote:
> Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec. 
> So, I suggest to remove prefix EFI_. 
> 
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca] 
> Sent: Monday, December 9, 2013 8:45 PM
> To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz
> Subject: [edk2] GUID for Flattened Device Tree in configuration table.
> 
> Hi all,
> 
> We (Linaro) are working on support for passing a flattened device tree
> (FDT) via the UEFI configuration table. Before we publish patches, I want to 
> make sure that we've generated a valid UUID for the FDT entry.
> We used the Linux tool uuidgen and it produced this:
> 
> #define EFI_DEVICE_TREE_GUID \
>   { \
> 0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 
> 0xe0 } \
>   }
> 
> I'm asking here to make sure we haven't made a fundamental error that gets 
> implemented by some firmware. Have we done the right thing?
> 
> g.
> 
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] GUID for Flattened Device Tree in configuration table.

[Gao, Liming]

Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec. 
So, I suggest to remove prefix EFI_. 

-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca] 
Sent: Monday, December 9, 2013 8:45 PM
To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz
Subject: [edk2] GUID for Flattened Device Tree in configuration table.

Hi all,

We (Linaro) are working on support for passing a flattened device tree
(FDT) via the UEFI configuration table. Before we publish patches, I want to 
make sure that we've generated a valid UUID for the FDT entry.
We used the Linux tool uuidgen and it produced this:

#define EFI_DEVICE_TREE_GUID \
  { \
0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0 
} \
  }

I'm asking here to make sure we haven't made a fundamental error that gets 
implemented by some firmware. Have we done the right thing?

g.

--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] GUID for Flattened Device Tree in configuration table.

[Grant Likely]

Hi all,

We (Linaro) are working on support for passing a flattened device tree
(FDT) via the UEFI configuration table. Before we publish patches, I
want to make sure that we've generated a valid UUID for the FDT entry.
We used the Linux tool uuidgen and it produced this:

#define EFI_DEVICE_TREE_GUID \
  { \
0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69,
0xaa, 0xe0 } \
  }

I'm asking here to make sure we haven't made a fundamental error that
gets implemented by some firmware. Have we done the right thing?

g.

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Move RTSM VExpress variable storage to 256k flash blocks

[Ryan Harkin]

Hi Roy,

This patch is in 2013.12-rc1 now and I am no longer able to save my
config in the models.  Can you confirm if it works for you and what
setup you are testing?

I see this on each boot:

Loading driver at 0x000BF54D000 EntryPoint=0x000BF54D26D ArmVeNorFlashDxe.efi
ValidateFvHeader: No Firmware Volume header present
NorFlashFvbInitialize: ERROR - The FVB Header is not valid. Installing
a correct one for this volume.
Ftw: Work block header check error
Ftw: Work block header check error
Ftw: Both are invalid, init workspace

Cheers,
Ryan.



On 6 December 2013 23:01, Roy Franz  wrote:
> Change the addresses/sizes of the variable storage areas to use 256k
> blocks so UEFI is compatible with both the RTSM models and QEMU.
>
> The VExpress flash has non-uniform block sizes, with most blocks being
> 256k and the top 4 blocks being 64k.  UEFI has been using these top 64k
> blocks for persistent variable storage.  The RTSM models the non-uniform
> sizes, while QEMU only supports emulating flash with uniform block sizes
> which results in the top 256k (the 4 64k blocks) of flash being unusable
> for writing in QEMU.
>
> Note that this change will require RTSM flash images to be updated, as
> the variable storage has moved.  Currently on the A15 model is supported
> by QEMU, but the A9 configuration is being updated as well to keep all
> RTSM VExpress configurations consistent.
>
> Signed-off-by: Roy Franz 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Steven Kinney 
> ---
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc |   12 
> ++--
>  .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |   12 
> ++--
>  ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc|   12 
> ++--
>  3 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc 
> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
> index 2d12f4b..8883213 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc
> @@ -77,12 +77,12 @@
>#
># NV Storage PCDs. Use base of 0x0C00 for NOR1
>#
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FFC
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FFD
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FFE
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FF0
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FF4
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FF8
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
>
>gArmTokenSpaceGuid.PcdVFPEnabled|1
>
> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc 
> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
> index efd80ab..ae42de2 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
> @@ -79,12 +79,12 @@
>#
># NV Storage PCDs. Use base of 0x0C00 for NOR1
>#
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FFC
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FFD
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FFE
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|0x0FF0
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0x0FF4
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0004
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0x0FF8
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0004
>
>gArmTokenSpaceGuid.PcdVFPEnabled|1
>
> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc 
> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc
> index b635502..4d4d8b1 100644
> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc
> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc
> @@ -81,12 +81,12 @@
>#
># NV Storage PCDs. Use base of 0x0C00 for NOR1
>#
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdF

Re: [edk2] [PATCH] Clean up hard-coded offsets and other utter bogosity in Thunk16.S.

[David Woodhouse]

On Mon, 2013-12-09 at 09:38 +, Gao, Liming wrote:
> David:
>   I have some comments. 
> 1. This patch just cleans up hard coded offset. So, it should still be
> compiled to the same binary instruction to original one. Have you
> compared the binary instruction? If the binary is different, how to
> make sure its functionality is same?

I covered this in my original commit message. There are a few trivial
differences where the assembler uses a 16-bit offset instead of an 8-bit
offset for a register-based address, and I even gave an example:

-  ab:  8d 46 0clea0xc(%bp),%ax
+  ab:  8d 86 0d 00 lea0xd(%bp),%ax

As I said, these are harmless. I have tested the code on OVMF under KVM,
and also on a real 32-bit platform (which required my later patch).

> 2. I see Andrew mentions llvm doesn't support 16-bit mode. So, this
> change will cause llvm/clang/Xcode build failure. Right?

Yes. I prodded Andrew in private email about that when he didn't
respond, in fact. And we have since had the discussion about the S3
resume trampoline which has similar issues. In that discussion, Andrew
said:

"Given the thrash on these [other] 2 files, maybe it worth doing the GNU
native mnemonics version to get things working and then porting that
back to llvm after it is stable?"

Given that we're already planning to do that elsewhere in EDKII, I think
it's a good idea here too. In fact, perhaps I should have answered your
question by saying "No. It won't break the LLVM build because the LLVM
build will be broken already." :)

Let's fix things using sane mnemonics that actually say what they mean —
and then *later* once it's entirely stable we can look at making it
unmaintainable by turning it into .byte arrays or whatever we need to do
to make it build with broken toolchains... if they really haven't fixed
the toolchain by then.

In the interim, I will personally fund a licence for GNU gas for any
affected individuals who need it to compile the code.

> 3. I see your another change to simplify the code. What's the benefit
> of this change? 

That one isn't just a simplification. It's a fix for a violation of the
SDM which causes failures on real hardware.

See Vol 3A §9.9.2 "Switching back to Real-Address Mode". The existing
code violates these requirements in *many* ways. The most important
violation for me right now is that the first instruction after clearing
CR0.PE *must* be a far JMP. We currently do some other stuff, followed
by a far RET. Which doesn't work on the board I'm playing with this
week.

I still need to try to set up a Windows build environment (or at least
get a copy of MASM.EXE I can run under Wine) and test the corresponding
changes in the Ia32/Thunk16.asm version, so I can submit that patch for
real.

> 4. For MdePkg\Library\BaseLib\X64\Thunk16.S, have you found the
> similar issue? 

That's a different can of worms, which *also* violates the SDM in some
of the same ways, and also wants cleaning up. But that's a separate
sequence of patches and not actually on my critical path to making
things work on real hardware this week.

However, since you mention it, we should probably sync up with the code
in EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/
which *is* almost identical. I note it's already missed out on the most
recent bug-fix (r14037).

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint not working in DxeServicesLib.c)

[bhupesh.sha...@freescale.com]

Many thanks Olivier. I will try to get deeper into the cause of gST->ConOut 
being NULL.

Any pointers to my 2nd doubt:

2. I was looking at the 'StartDefaultBootOnTimeout' function implementation 
inside Bds.c
   (https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/Bds/Bds.c#L322)
   and cannot seem to understand which timer (the Metronome one  or the 
Periodic one will be called here)
   will be called to implement a timer event. To me it seems the Periodic timer 
(TimerDxe rather than the
   TimerLib) would be involved here.

   Also, I think that since my gST->ConIn and gST->ConOut are both NULL, the 
'StartDefaultBootOnTimeout'
   function will never get a gST->ConIn->WaitForKey and hence the default boot 
should start after
   'PcdPlatformBootTimeOut' interval.

Is this understanding correct?

Regards,
Bhupesh


> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: Monday, December 09, 2013 3:35 PM
> To: Sharma Bhupesh-B45370; 'Andrew Fish'; edk2-
> de...@lists.sourceforge.net
> Subject: RE: gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint
> not working in DxeServicesLib.c)
> 
> Unfortunately, you will need to trace your execution by yourself.
> Everything seems correct but you might have missed a dependency in your
> code (check library assignment in DSC file) or got an error in your code
> path.
> Use DEBUG() macro or debugger to trace your execution.
> Try to understand why ConSplitterDxe does not set gST->ConIn and gST-
> >ConOut might a good starting point.
> 
> > -Original Message-
> > From: bhupesh.sha...@freescale.com
> > [mailto:bhupesh.sha...@freescale.com]
> > Sent: 09 December 2013 07:07
> > To: Olivier Martin; bhupesh.sha...@freescale.com; 'Andrew Fish'; edk2-
> > de...@lists.sourceforge.net
> > Subject: RE: gST->ConOut is NULL and Timer issues (Was: RE:
> > SerialPrint not working in DxeServicesLib.c)
> >
> > Hi Olivier and Andrew,
> >
> > Thanks for your respective suggestions. Accordingly I checked out my
> > code and found out that:
> >
> > 1.  I checked the relevant stuff in the DSC and FDF files and I have
> > the following entries related to ConOut and ConIn:
> >
> >   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> >   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> >
> > MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.i
> > n
> > f
> >   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> >   EmbeddedPkg/SerialDxe/SerialDxe.inf
> >
> >   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE
> >
> >   # Use the serial console for both ConIn & ConOut
> >   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> > 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();"
> >   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-
> > 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> >
> >   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2E
> >
> >   I can see the DEBUG() prints and well as the AsciiSPrint() on the
> > console, but can't get any console output for the Print() directives.
> >
> > 2. I was looking at the 'StartDefaultBootOnTimeout' function
> > implementation inside Bds.c
> > (https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/Bds/Bds.
> > c
> > #L322)
> >and cannot seem to understand which timer (the Metronome one  or
> > the Periodic one will be called here) will be called to implement a
> > timer event. To me
> >it seems the Periodic timer (TimerDxe rather than the TimerLib)
> > would be involved here.
> >
> >Also, I think that since my gST->ConIn and gST->ConOut are both
> > NULL, the 'StartDefaultBootOnTimeout' function will never get a gST-
> > >ConIn->WaitForKey
> >and hence the default boot should start after
> > 'PcdPlatformBootTimeOut' interval.
> >
> > Is this understanding correct?
> >
> > Regards,
> > Bhupesh
> >
> > > -Original Message-
> > > From: Olivier Martin [mailto:olivier.mar...@arm.com]
> > > Sent: Tuesday, December 03, 2013 4:48 PM
> > > To: Sharma Bhupesh-B45370; 'Andrew Fish'; edk2-
> > > de...@lists.sourceforge.net
> > > Subject: RE: gST->ConOut is NULL and Timer issues (Was: RE:
> > SerialPrint
> > > not working in DxeServicesLib.c)
> > >
> > > Because you are using SerialDxe (see
> > > 'VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)'), ensure you have the
> > > following drivers in your DSC and FDF files:
> > > - MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> > > - MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > > - MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> > >
> > > ConSplitterDxe is the driver that will set gST->ConOut in this
> > scenario.
> > >
> > > Olivier
> > >
> > >
> > > > -Original Message-
> > > > From: Bhupesh Sharma [mailto:bhupesh.sha...@freescale.com]
> > > > Sent: 02 December 2013 11:09
> > > > To: Olivier Martin; 'Andrew Fish'; 'edk2-
> > de...@lists.

Re: [edk2] gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint not working in DxeServicesLib.c)

[Olivier Martin]

Unfortunately, you will need to trace your execution by yourself.
Everything seems correct but you might have missed a dependency in your code
(check library assignment in DSC file) or got an error in your code path.
Use DEBUG() macro or debugger to trace your execution.
Try to understand why ConSplitterDxe does not set gST->ConIn and gST->ConOut
might a good starting point.

> -Original Message-
> From: bhupesh.sha...@freescale.com
> [mailto:bhupesh.sha...@freescale.com]
> Sent: 09 December 2013 07:07
> To: Olivier Martin; bhupesh.sha...@freescale.com; 'Andrew Fish'; edk2-
> de...@lists.sourceforge.net
> Subject: RE: gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint
> not working in DxeServicesLib.c)
> 
> Hi Olivier and Andrew,
> 
> Thanks for your respective suggestions. Accordingly I checked out my
> code and found out that:
> 
> 1.  I checked the relevant stuff in the DSC and FDF files and I have
> the following entries related to ConOut and ConIn:
> 
>   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> 
> MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.in
> f
>   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
>   EmbeddedPkg/SerialDxe/SerialDxe.inf
> 
>   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE
> 
>   # Use the serial console for both ConIn & ConOut
>   gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();"
>   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> 
>   gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2E
> 
>   I can see the DEBUG() prints and well as the AsciiSPrint() on the
> console, but can't get any console output for the Print() directives.
> 
> 2. I was looking at the 'StartDefaultBootOnTimeout' function
> implementation inside Bds.c
> (https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/Bds/Bds.c
> #L322)
>and cannot seem to understand which timer (the Metronome one  or the
> Periodic one will be called here) will be called to implement a timer
> event. To me
>it seems the Periodic timer (TimerDxe rather than the TimerLib)
> would be involved here.
> 
>Also, I think that since my gST->ConIn and gST->ConOut are both
> NULL, the 'StartDefaultBootOnTimeout' function will never get a gST-
> >ConIn->WaitForKey
>and hence the default boot should start after
> 'PcdPlatformBootTimeOut' interval.
> 
> Is this understanding correct?
> 
> Regards,
> Bhupesh
> 
> > -Original Message-
> > From: Olivier Martin [mailto:olivier.mar...@arm.com]
> > Sent: Tuesday, December 03, 2013 4:48 PM
> > To: Sharma Bhupesh-B45370; 'Andrew Fish'; edk2-
> > de...@lists.sourceforge.net
> > Subject: RE: gST->ConOut is NULL and Timer issues (Was: RE:
> SerialPrint
> > not working in DxeServicesLib.c)
> >
> > Because you are using SerialDxe (see
> > 'VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)'), ensure you have the
> > following drivers in your DSC and FDF files:
> > - MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> > - MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > - MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> >
> > ConSplitterDxe is the driver that will set gST->ConOut in this
> scenario.
> >
> > Olivier
> >
> >
> > > -Original Message-
> > > From: Bhupesh Sharma [mailto:bhupesh.sha...@freescale.com]
> > > Sent: 02 December 2013 11:09
> > > To: Olivier Martin; 'Andrew Fish'; 'edk2-
> de...@lists.sourceforge.net'
> > > Subject: gST->ConOut is NULL and Timer issues (Was: RE: SerialPrint
> > > not working in DxeServicesLib.c)
> > >
> > > Hi,
> > >
> > > I managed to trace down the issues with my UEFI ported code for a
> > > Cortex-A9 MP core based SoC.
> > >
> > > I see two issues (after solving a few on the way) on which I cannot
> > > seem to make any headway.
> > >
> > > 1. gST->ConOut is NULL causing the Print routines inside
> > > StartDefaultBootOnTimeout
> > >
> > >
> (https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/Bds/Bds.
> > > c
> > > #L327), to not print
> > >   anything on the UART console.
> > >
> > >   - At first, I suspected this to be an issue with my .dsc file as
> I
> > > don't have a LCD available on my SoC
> > > and I had serial port as well as (a left over) LCD configured
> as
> > > SIMPLE TEXT protocols for ConOut.
> > > I have hence changed my .dsc to something like:
> > >
> > >   # Use the serial console for both ConIn & ConOut
> > >
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> > > 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();"
> > >   gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-
> > > 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> > >
> > >   However, still I see that gST->ConOut is NULL (via

Re: [edk2] [PATCH] Clean up hard-coded offsets and other utter bogosity in Thunk16.S.

[Gao, Liming]

David:
  I have some comments. 
1. This patch just cleans up hard coded offset. So, it should still be compiled 
to the same binary instruction to original one. Have you compared the binary 
instruction? If the binary is different, how to make sure its functionality is 
same?
2. I see Andrew mentions llvm doesn't support 16-bit mode. So, this change will 
cause llvm/clang/Xcode build failure. Right?
3. I see your another change to simplify the code. What's the benefit of this 
change? 
4. For MdePkg\Library\BaseLib\X64\Thunk16.S, have you found the similar issue? 

Thanks
Liming
-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org] 
Sent: Saturday, November 30, 2013 12:14 AM
To: edk2-devel@lists.sourceforge.net
Cc: Gao, Liming
Subject: [PATCH] Clean up hard-coded offsets and other utter bogosity in 
Thunk16.S.

Again.

Properly this time.

In r12889 we attempted to clean this up, but we missed a vital part of
it, so it was reverted in r12898.

What we missed was the fact that much of this is 16-bit code, and the
assembler didn't *know* that — it thought it was compiling 32-bit code
and we had even gone out of our way to entertain that fiction, for
example writing:
mov %edx, %cs:0xffc5(%esi)
when we really meant:
mov %dx, %cs:(SavedSs - L_Base)(%bp)

Note that even the *registers* are different here. The address really is
based on %bp, not %esi. We only said %esi to trick the assembler.

If we're lying to the assembler about the context and it doesn't even
know whether operands are 32-bit or 16-bit, how on earth did we expect
it to calculate offsets correctly for us? Of *course* it went wrong!

So this brings back the fixes from r12889, and also fixes up the 16-bit
code to be sane again. Doing a direct comparison of the output I see
some minor changes, mostly because the compiler can't output 8-bit
relocations in x86_32 ELF, so even if an offset does fit in 8 bits, the
assembler will use a 16-bit offset instead. So we get minor differences
in the output such as:

-  ab:  8d 46 0clea0xc(%bp),%ax
+  ab:  8d 86 0d 00 lea0xd(%bp),%ax

but those really are harmless — at least they are now that we aren't
hard-coding addresses and breaking because code moves around by a single
byte!

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse 
---
 MdePkg/Library/BaseLib/Ia32/Thunk16.S | 121 --
 1 file changed, 71 insertions(+), 50 deletions(-)

diff --git a/MdePkg/Library/BaseLib/Ia32/Thunk16.S 
b/MdePkg/Library/BaseLib/Ia32/Thunk16.S
index 8356c5a..331ea16 100644
--- a/MdePkg/Library/BaseLib/Ia32/Thunk16.S
+++ b/MdePkg/Library/BaseLib/Ia32/Thunk16.S
@@ -24,6 +24,28 @@
 ASM_GLOBAL ASM_PFX(m16Start), ASM_PFX(m16Size), ASM_PFX(mThunk16Attr), 
ASM_PFX(m16Gdt), ASM_PFX(m16GdtrBase), ASM_PFX(mTransition)
 ASM_GLOBAL ASM_PFX(InternalAsmThunk16)
 
+# define the structure of IA32_REGS
+.set  _EDI, 0   #size 4
+.set  _ESI, 4   #size 4
+.set  _EBP, 8   #size 4
+.set  _ESP, 12  #size 4
+.set  _EBX, 16  #size 4
+.set  _EDX, 20  #size 4
+.set  _ECX, 24  #size 4
+.set  _EAX, 28  #size 4
+.set  _DS,  32  #size 2
+.set  _ES,  34  #size 2
+.set  _FS,  36  #size 2
+.set  _GS,  38  #size 2
+.set  _EFLAGS, 40   #size 4
+.set  _EIP, 44  #size 4
+.set  _CS, 48   #size 2
+.set  _SS, 50   #size 2
+.set  IA32_REGS_SIZE, 52
+
+.text
+.code16
+
 ASM_PFX(m16Start):
 
 SavedGdt: .space  6
@@ -31,21 +53,22 @@ SavedGdt: .space  6
 ASM_PFX(BackFromUserCode):
 push%ss
 push%cs
-.byte   0x66
-callL_Base1 # push eip
+
+calll   L_Base1 # push eip
 L_Base1:
-pushfw  # pushfd actually
+pushfl
 cli # disable interrupts
 push%gs
 push%fs
 push%es
 push%ds
-pushaw  # pushad actually
+pushal
 .byte   0x66, 0xba  # mov edx, imm32
 ASM_PFX(ThunkAttr): .space  4
 testb   $THUNK_ATTRIBUTE_DISABLE_A20_MASK_INT_15, %dl
 jz  1f
-movl$0x15cd2401, %eax   # mov ax, 2401h & int 15h
+movw$0x2401, %ax
+int $0x15
 cli # disable interrupts
 jnc 2f
 1:
@@ -55,27 +78,26 @@ ASM_PFX(ThunkAttr): .space  4
 orb $2, %al
 outb%al, $0x92  # deactivate A20M#
 2:
-xorw%ax, %ax# xor eax, eax
-movl%ss, %eax   # mov ax, ss
-.byte   0x67, 0x66, 0x8d, 0x6c, 0x24, 0x34, 0x66
-mov %ebp, 0xffd8(%esi)
-mov 0xfff8(%esi), %ebx
-shlw$4, %ax # shl eax, 4
-addw%ax, %bp# add ebp, eax
-.byte   0x66, 0xb8   # mov eax, imm32
+xorl%eax, %eax
+movw%ss, %ax
+lealIA32_