On 06/08/15 23:46, Laszlo Ersek wrote: > At the moment we work with a UC default MTRR type, and set three memory > ranges to WB: > - [0, 640 KB), > - [1 MB, LowerMemorySize), > - [4 GB, 4 GB + UpperMemorySize). > > Unfortunately, coverage for the third range can fail with a high > likelihood. If the alignment of the base (ie. 4 GB) and the alignment of > the size (UpperMemorySize) differ, then MtrrLib creates a series of > variable MTRR entries, with power-of-two sized MTRR masks. And, it's > really easy to run out of variable MTRR entries, dependent on the > alignment difference. > > This is a problem because a Linux guest will loudly reject any high memory > that is not covered my MTRR. > > So, let's follow the inverse pattern (loosely inspired by SeaBIOS): > - flip the MTRR default type to WB, > - set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default > type and variable MTRRs, so we can't avoid this, > - set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs, > - set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs > more likely than the other scheme (due to less chaotic alignment > differences). > > Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000) > in PcdDebugPrintErrorLevel. > > BUG: Although the MTRRs look good to me in the OVMF debug log, I still > can't boot >= 64 GB guests with this. Instead of the complaints mentioned > above, the Linux guest apparently spirals into an infinite loop (on KVM), > or hangs with no CPU load (on TCG).
No, actually there is no bug in this patch (so s/RFC/PATCH/). I did more testing and these are the findings: - I can reproduce the same issue on KVM with SeaBIOS guests. - The exact symptoms are that as soon as the highest guest-phys address is >= 64 GB, then the guest kernel doesn't boot. It gets stuck somewhere after hitting Enter in grub. - Normally 3 GB of the guest RAM is mapped under 4 GB in guest-phys address space, then there's a 1 GB PCI hole, and the rest is above 4 GB. This means that a 63 GB guest can be started (because 63 - 3 + 4 == 64), but if you add just 1 MB more, it won't boot. - (This was the big discovery:) I flipped the "ept" parameter of the kvm_intel module on my host to N, and then things started to work. I just booted a 128 GB Linux guest with this patchset. (I have 4 GB RAM in my host, plus approx 250 GB swap.) The guest could see it all. - The TCG boot didn't hang either; I just couldn't wait earlier for network initialization to complete. I'm CC'ing Paolo for help with the EPT question. Other than that, this series is functional. (For QEMU/KVM at least; Xen will likely need more fixes from others.) Thanks Laszlo > > Cc: Maoming <maoming.maom...@huawei.com> > Cc: Huangpeng (Peter) <peter.huangp...@huawei.com> > Cc: Wei Liu <wei.l...@citrix.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek <ler...@redhat.com> > --- > OvmfPkg/PlatformPei/MemDetect.c | 43 > +++++++++++++++++++++++++++++++++++++---- > 1 file changed, 39 insertions(+), 4 deletions(-) > > diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c > index 3ceb142..cceab22 100644 > --- a/OvmfPkg/PlatformPei/MemDetect.c > +++ b/OvmfPkg/PlatformPei/MemDetect.c > @@ -194,6 +194,8 @@ QemuInitializeRam ( > { > UINT64 LowerMemorySize; > UINT64 UpperMemorySize; > + MTRR_SETTINGS MtrrSettings; > + EFI_STATUS Status; > > DEBUG ((EFI_D_INFO, "%a called\n", __FUNCTION__)); > > @@ -214,12 +216,45 @@ QemuInitializeRam ( > } > } > > - MtrrSetMemoryAttribute (BASE_1MB, LowerMemorySize - BASE_1MB, > CacheWriteBack); > + // > + // We'd like to keep the following ranges uncached: > + // - [640 KB, 1 MB) > + // - [LowerMemorySize, 4 GB) > + // > + // Everything else should be WB. Unfortunately, programming the inverse > (ie. > + // keeping the default UC, and configuring the complement set of the above > as > + // WB) is not reliable in general, because the end of the upper RAM can > have > + // practically any alignment, and we may not have enough variable MTRRs to > + // cover it exactly. > + // > + if (IsMtrrSupported ()) { > + MtrrGetAllMtrrs (&MtrrSettings); > > - MtrrSetMemoryAttribute (0, BASE_512KB + BASE_128KB, CacheWriteBack); > + // > + // MTRRs disabled, fixed MTRRs disabled, default type is uncached > + // > + ASSERT ((MtrrSettings.MtrrDefType & BIT11) == 0); > + ASSERT ((MtrrSettings.MtrrDefType & BIT10) == 0); > + ASSERT ((MtrrSettings.MtrrDefType & 0xFF) == 0); > > - if (UpperMemorySize != 0) { > - MtrrSetMemoryAttribute (BASE_4GB, UpperMemorySize, CacheWriteBack); > + // > + // flip default type to writeback > + // > + SetMem (&MtrrSettings.Fixed, sizeof MtrrSettings.Fixed, 0x06); > + ZeroMem (&MtrrSettings.Variables, sizeof MtrrSettings.Variables); > + MtrrSettings.MtrrDefType |= BIT11 | BIT10 | 6; > + MtrrSetAllMtrrs (&MtrrSettings); > + > + // > + // punch holes > + // > + Status = MtrrSetMemoryAttribute (BASE_512KB + BASE_128KB, > + SIZE_256KB + SIZE_128KB, CacheUncacheable); > + ASSERT_EFI_ERROR (Status); > + > + Status = MtrrSetMemoryAttribute (LowerMemorySize, > + SIZE_4GB - LowerMemorySize, CacheUncacheable); > + ASSERT_EFI_ERROR (Status); > } > } > > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel