On Sat, Sep 21, 2013 at 8:08 AM, Laszlo Ersek <[email protected]> wrote: > On 09/18/13 13:19, Laszlo Ersek wrote: >> Rod, >> >> On 09/18/13 01:24, Jordan Justen wrote: >>> QEMU 1.6 enables using KVM READONLY memory regions. There >>> appears to be a bug when page tables are stored in the >>> READONLY memory region. To work-around this, we create >>> page table entries in RAM. Since RAM is present in QEMU/KVM >>> without any initialization, this is easily accomplished >>> for OVMF. >>> >>> Since the firmware-device no longer needs to store 24KB of >>> uncompressed page table data, we also reclaim nearly all >>> of that for use with OVMF's compressed firmware. >> >> Can you please test this series on your AMD machine? Your previous >> config should work (qemu-1.6, recent (3.10+ ?) kernel, KVM enabled). >> >> If the series doesn't help on AMD, IMO that should *not* block this >> series. However if it fixes the AMD case too, then maybe one of the >> commit messages could mention that. >> >> CC'ing Paolo & Gleb, and also here's a reference into the earlier >> discussion: >> >> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3961 >> >> In that thread I think I tested this series on AMD (then-available >> from Jordan's tree) and it technically fixed the problem on SVM too, >> but it seemed to incur (or expose) a ~40 sec busy loop at startup, >> with many EXIT_INTRs in KVM. >> >> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/3961/focus=3998 >> >> But, again, if this symptom persists on SVM, I don't think it should >> block this series. > > I couldn't resist and had to test the series on AMD too. I realized I > could permanently enlist my home Debian Wheezy desktop for quick > turn-around :) > > Host CPU: AMD Athlon(tm) II X2 B22 Processor > Host kernel: 3.11.1 (fresh from kernel.org) > KVM: in use > QEMU: 1.6.50 (at commit 6c2679fc19560699679200fb42ab4659bcbe7f79) > > The symptoms I'm seeing are identical to those in the thread linked > above: > > (1) When starting qemu with OVMF, there's a long loop (about 1min) when > apparently nothing happens, but qemu is working very hard: > > SecCoreStartupWithStack(0xFFFCC000, 0x80000) > File->Type: 0xB > Section->Type: 0x2 > ----[LONG LOOP HERE]---- > Section->Type: 0x19 > Section->Type (0x19) != SectionType (0x17) > Section->Type: 0x17 > File->Type: 0x2 > File->Type (0x2) != FileType (0x4) > > (2) After the long loop, OVMF continues to load and it can start the > UEFI shell, the config TUI etc. Everything seems normal. > > The debug messages quoted above help: > > SecCoreStartupWithStack() > [OvmfPkg/Sec/SecMain.c] > // prints "SecCoreStartupWithStack(0xFFFCC000, 0x80000)" > InitializeDebugAgent() > [MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.c] > SecStartupPhase2() > [OvmfPkg/Sec/SecMain.c] > FindAndReportEntryPoints() > FindPeiCoreImageBase() > DecompressGuidedFv() > FindFfsFileAndSection(..., > EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE == > 0x0B, [MdePkg/Include/Pi/PiFirmwareFile.h] > EFI_SECTION_GUID_DEFINED == > 0x02, [MdePkg/Include/Pi/PiFirmwareFile.h] > ...) > // prints "File->Type: 0xB" > FindFfsSectionInSections() > // prints "Section->Type: 0x2" > ExtractGuidedSectionGetInfo() > ExtractGuidedSectionDecode() <------ long loop runs here > FindFfsSectionInSections(..., > EFI_SECTION_FIRMWARE_VOLUME_IMAGE == > 0x17, [MdePkg/Include/Pi/PiFirmwareFile.h] > ...) > // prints "Section->Type: 0x19" > // prints "Section->Type (0x19) != SectionType (0x17)" > // prints "Section->Type: 0x17" > > I think that ExtractGuidedSectionDecode() decompresses the compressed > part of the firmware image, and that it takes unusually long probably > because the initial 4GB mapping we've set up in the reset vector > disables caching for all pages covered. (Not sure why that doesn't cause > such a visible difference on VMX -- maybe different defaults?) Later on, > in "MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c", we build page > tables that enable caching. > > For what it's worth, I committed the attached patch on top of this > series. This accelerates the OVMF startup on SVM to be on par with the > VMX experience. However, I'm not sure if it's *safe* to enable caching > that early! > > Until we figure this all out, I think the slower startup on AMD should > not be a problem; the series is strictly an improvement on AMD too.
I think your patch is a good change, and I want to add it to the middle of my series with this expanded commit message: OvmfPkg/ResetVector: enable caching in initial page tables In UEFI X64 we use other mechanisms to disable caching. (CD/NW in CR0 and MTRRs.) This fixes a slow boot issue with SVM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <[email protected]> Reviewed-by: Jordan Justen <[email protected]> ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
