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
