On 09/22/13 09:09, Gleb Natapov wrote:
> On Sat, Sep 21, 2013 at 04:52:02PM -0700, Jordan Justen wrote:
>> 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.)
>>
> Those will not disable cache in a guest, but I doubt disabling it
> achieves anything in virtualized environment.
>
>
>> This fixes a slow boot issue with SVM.
>>
> I wonder why don't we see the same slowdown on real HW?
There would be several configs to test, with the caching *disabled* in
the page table entries. Minimally:
- VMX with EPT: tested, fast,
- VMX without EPT: tested, fast (AFAIR),
- SVM with RVI: tested, slow (*),
- SVM without RVI: untested,
- bare metal Intel: fast (I guess?), in fact paralleling the VMX cases,
- bare metal AMD: untested (this is what you're raising now, IIUC).
(*) I checked the AMD docs, and
15 Secure Virtual Machine
15.25 Nested Paging
15.25.8 Combining Memory Types, MTRRs
says
[...] When nested paging is enabled, the processor combines guest and
nested page table memory types. Registers that affect memory types
include:
- The PCD/PWT/PATi bits in the nested and guest page table entries.
[...]
- gCR0.CD and hCR0.CD.
I guess this explains why we're seeing the slowdown with the PCD set in
the guest PTEs. I don't know why we don't have the same experience on
VMX+EPT.
Regarding CR0.CD: the passage I qouted above seems to imply gCR0.CD
should be effective.
CR0.NW seems to be generally "useless" though (3.1.1 CR0 Register; 7.6.2
Cache Control Mechanisms).
In any case, I enthusiastically share your doubt (from your other email)
that "disabling [caching] achieves anything in virtualized environment".
Thanks!
Laszlo
------------------------------------------------------------------------------
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/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
