Re: [edk2] Sync notes review for Grantley

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

Re: [edk2] uUEFI code execution

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:

[edk2] Sync notes review for Grantley

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

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

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)

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

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

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

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

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 ma

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

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

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 outs

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

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 (SeaBIO

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

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

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 S3Rest

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

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) targe

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

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 th

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

"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] gEfiSmmSwDispatc

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

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

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

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: Platfor

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

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 deleti

[edk2] [RFC v2 12/24] OvmfPkg: S3 Resume: introduce EmuSmmPei for emulating SMRAM in PEI

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

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

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

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

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 |

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

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 (beca

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

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: Lasz

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

"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/Generic

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

"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. S3SaveStat

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

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/Pl

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

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/O

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

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_RUN

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

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/.../PeiServices

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

"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

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

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

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

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

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

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

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

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

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

"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()

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

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 BdsLibBoot

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

Re: [edk2] uUEFI code execution

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 a

Re: [edk2] ShellPkg: Remove invalid ASSERT

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? S

[edk2] 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 Rm.c.patch Descripti

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

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 suppor

[edk2] 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 ctrl-c_support_prompts.patch Description: ctrl-c_sup

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

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, th

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

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

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 re

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

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 Fran

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

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

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 Firmw

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

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 t

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

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

Re: [edk2] 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 ConSp

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

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 mentio