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
