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:

<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5297/focus=5321>
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
> 0x70000-0x80000. (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
<https://github.com/lersek/edk2/commits/s3_rfc_02> 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 Resume: pull in BootScriptExecutorDxe
  OvmfPkg: S3 Resume: pull in PEIM orchestrating S3 Resume
  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
  OvmfPkg: S3 Resume: detect S3 Resume in CMOS and set boot mode
    accordingly

 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf            |  78 +++
 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf        |  51 ++
 OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf                    |  55 ++
 OvmfPkg/EmuSmmPei/EmuSmmPei.inf                    |  60 ++
 OvmfPkg/PlatformPei/PlatformPei.inf                |   5 +
 OvmfPkg/Sec/SecMain.inf                            |   4 +
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |   1 +
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h                 |  59 ++
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c             |   3 +-
 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c                 | 605 +++++++++++++++++++++
 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c          |  38 ++
 OvmfPkg/EmuSmmDxe/EmuSmmDxe.c                      | 276 ++++++++++
 OvmfPkg/EmuSmmPei/EmuSmmPei.c                      | 285 ++++++++++
 OvmfPkg/PlatformPei/Fv.c                           |  27 +-
 OvmfPkg/PlatformPei/Platform.c                     |  61 ++-
 OvmfPkg/Sec/SecMain.c                              |  35 ++
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  |  19 +-
 OvmfPkg/OvmfPkg.dec                                |  16 +
 OvmfPkg/OvmfPkgX64.dsc                             |  47 +-
 OvmfPkg/OvmfPkgX64.fdf                             |  65 ++-
 UefiCpuPkg/UefiCpuPkg.dec                          |   7 +
 21 files changed, 1755 insertions(+), 42 deletions(-)
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
 create mode 100644 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.inf
 create mode 100644 OvmfPkg/EmuSmmDxe/EmuSmmDxe.inf
 create mode 100644 OvmfPkg/EmuSmmPei/EmuSmmPei.inf
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.h
 create mode 100644 OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
 create mode 100644 OvmfPkg/DiscloseSmstSmm/DiscloseSmstSmm.c
 create mode 100644 OvmfPkg/EmuSmmDxe/EmuSmmDxe.c
 create mode 100644 OvmfPkg/EmuSmmPei/EmuSmmPei.c

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

Reply via email to