On 2015-07-14 14:29:11, Laszlo Ersek wrote: > On 07/14/15 23:15, Paolo Bonzini wrote: > >> The long delay that Alex reported (for the case when all guest memory > >> was set to UC up-front) is due to the fact that the SEC phase of OVMF > >> decompresses an approximately 1712 KB sized, LZMA-compressed blob, to > >> approx. 896 KB worth of PEI drivers and 8192 KB worth of DXE and UEFI > >> drivers -- and this decompression is extremely memory-intensive. > >> > >> (When Jordan implemented that reset vector first, we saw similar > >> performance degradation on AMD hosts (albeit not due to MTRR but due to > >> page attributes). See > >> <https://github.com/tianocore/edk2/commit/98f378a7>. I'm only mentioning > >> it here because it makes me appreciate the current problem report.) > >> > >> Anyway, the reset vector's page table building is implemented in > >> "OvmfPkg/ResetVector/Ia32/PageTables64.asm". The decompression in SEC > >> can be found in "OvmfPkg/Sec/SecMain.c", function DecompressMemFvs(). > > > > Perhaps the OVMF reset vector should initialize the MTRRs for the BSP? > > That's an idea, yes, if someone feels sufficiently drawn to writing > assembly.
Maybe we can use MtrrLib in the SEC C code? -Jordan > Complications: > - the reset vector is specific to OvmfPkg only in the OvmfPkgX64.dsc > build > - it needs to be determined what memory to cover. > > > I think SEC doesn't do any MMIO, so it should be enough to enable MTRRs > > and set the default type to writeback. > > Seems safe to me, off the top of my head (and testing could confirm / > disprove quickly). > > > In any case we're going to have to quirk it, because of the broken > > guests in the wild. > > Thanks. > Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
