On Tue, Dec 3, 2013 at 9:46 PM, Laszlo Ersek <ler...@redhat.com> wrote: >> Install PPI: 88C9D306-0900-4EB5-8260-3E2DBEDA1F89 >> Install PPI: 605EA650-C65C-42E1-BA80-91A52AB618C6 > > These two PPIs (BootScriptDonePpi, EndOfPeiPpi) are installed by > S3ResumeBootOs() early. > >> Transfer to 16bit OS waking vector - 9A1D0 > > In my testing anyway, which is case #2 from the above list, the > AsmTransferControl() assembly code is invoked, implemented in > MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/S3Asm.S. > >> SecCoreStartupWithStack(0xFFFCC000, 0x80000) > > And, it reboots the virtual machine. It's an infinite reboot loop > actually, always going through the same resume path and rebooting in the > same spot.
Does the OS waking vector appear to have some code? 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) (I *very briefly* looked over your patches, and I didn't notice them taking this into account. Sorry if I missed it.) -Jordan ------------------------------------------------------------------------------ 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
