On 12/11/13 12:33, Laszlo Ersek wrote: > I get reliable suspend and resume with this series. Tested the X64 and > the Ia32X64 builds, with an X64 Fedora 19 guest. Nothing seems to be > corrupted, X11 makes no difference wrt. stability. The guest even > withstands repeated suspends and resumes in a row. Ssh connections to > the guest via virtio-net survive the suspend/resume intact. The display > does die, but that's something to be figured out later -- it might > involve guest kernel debugging. > > I also tracked/eyeballed a bunch of interesting pointers in the logs > (OVMF's and the Linux EFI memmap dump), from cold boot to resume, > verifying types and ranges. > > Changes in this version, in comparison to rfc2: > > - Introduced EmuNvramLib which simply describes three separate address > ranges that we need to survive suspend / resume. The address ranges > are: SMRAM (for SMM / LockBox stuff), storage for the SMST pointer, > and backing store for permanent PEI core memory on the resume path. > > - Following Jiewen's advice, implemented the correct lifecycle for > permanent PEI core memory on the resume path. This proved critical in > avoiding guest OS corruption. It also allowed me to drop several > patches, MdeModulePkg and UefiCpuPkg included, that had approached > this from the wrong side. > > - Reordered patches so that PlatformPei / memory reservation ones > gravitate to the beginning of the series. "S3 Suspend" and "S3 Resume" > patches are about drivers. > > - Added Jiewen's R-b to the UefiCpuPkg patch. > > - Replicated the FDF and DSC changes to the 32 and 32/64 platforms > throughout. > > The series should not regress any use pattern that lacks suspend/resume. > > Please test and/or review.
I'll need another patch (similar to 08/22) that reserves the RAM area hosting the initial X64 page tables (created by the special reset vector code), in [0x80000..0x86000[. That is, 24KB from 512KB onwards. I can post that as a followup (23/22) or I can post a v2 series with it between v1 08/22 and v2 09/22. I should probably also expand the memory map in the README (or perhaps add a new text file), maybe with a new patch, so that it gives a (more) complete picture. I found this problem (lack of reservation) by staring at the ceiling at night, not by testing. I assume all three of Linux, Windows 2008 and Windows 2012 try hard to conserve low RAM (for legacy DMA etc), which is probably why overwriting this low 24KB without reserving it has never caused problems in my testing -- the OSes likely put nothing there anyway without legacy DMA and/or extreme memory pressure. Thanks Laszlo ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
