OvmfPkg/Microvm/MicrovmX64.dsc | 3 +++ OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++ OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/MemDetect.c | 5 +++++ 4 files changed, 12 insertions(+)
Gerd Hoffmann (3): OvmfPkg/PlatformInitLib: check PcdUse1GPageTable OvmfPkg/OvmfPkgIa32X64: enable 1G pages OvmfPkg/MicrovmX64: enable 1G pages OvmfPkg/Microvm/MicrovmX64.dsc | 3 +++ OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++ OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/MemDetect.c | 5 +++++ 4 files changed, 12 insertions(+) -- 2.40.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104969): https://edk2.groups.io/g/devel/message/104969 Mute This Topic: https://groups.io/mt/98944976/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, 17 May 2023 at 12:24, Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > Gerd Hoffmann (3): > OvmfPkg/PlatformInitLib: check PcdUse1GPageTable > OvmfPkg/OvmfPkgIa32X64: enable 1G pages > OvmfPkg/MicrovmX64: enable 1G pages > Acked-by: Ard Biesheuvel <ardb@kernel.org> > OvmfPkg/Microvm/MicrovmX64.dsc | 3 +++ > OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++ > OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 + > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 5 +++++ > 4 files changed, 12 insertions(+) > > -- > 2.40.1 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105313): https://edk2.groups.io/g/devel/message/105313 Mute This Topic: https://groups.io/mt/98944976/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Wed, May 17, 2023 at 11:24 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > Gerd Hoffmann (3): > OvmfPkg/PlatformInitLib: check PcdUse1GPageTable > OvmfPkg/OvmfPkgIa32X64: enable 1G pages > OvmfPkg/MicrovmX64: enable 1G pages > > OvmfPkg/Microvm/MicrovmX64.dsc | 3 +++ > OvmfPkg/OvmfPkgIa32X64.dsc | 3 +++ > OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 + > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 5 +++++ > 4 files changed, 12 insertions(+) Just a passing comment: note that this change can have possibly bad side effects on reliability/performance. I noticed this a few days ago when snooping around info mem/tlb for various kernels and firmware. The Intel SDM and AMD manuals both mention possible bad side effects for having large pages (2MB/4MB/1GB) spanning multiple MTRRs. Quoting from the AMD manual (just for a change, the Intel SDM has similar passings plus a "we hacked it up because everyone was breaking it" clause for the lower ~2MB region of physical space): "When paging is enabled, software can use large page sizes (2 Mbytes and 4 Mbytes) in addition to the more typical 4-Kbyte page size. When large page sizes are used, it is possible for multiple MTRRs to span the memory range within a single large page. Each MTRR can characterize the regions within the page with different memory types. If this occurs, the effective memory-type used by the processor within the large page is undefined." As far as I know, EDK2 (or at least my local OVMF builds) do not handle this. In theory, you should break these particular large pages down. In practice, nothing bad seems to have come up yet (AFAIK), except poor-ish/poor-er performance. So this problem is still standing (I'm meaning to take a stab at this in the near future), but using 1GB pages may worsen the situation by increasing the nasty overlaps a heck of a lot more. While I don't expect my comment to be a blocker (particularly as other OVMF platforms are already using them), I think it's probably a good idea to let you know. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104988): https://edk2.groups.io/g/devel/message/104988 Mute This Topic: https://groups.io/mt/98944976/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Thu, May 18, 2023 at 12:16:21AM +0100, Pedro Falcato wrote: > On Wed, May 17, 2023 at 11:24 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > The Intel SDM and AMD manuals both mention possible bad side effects > for having large pages (2MB/4MB/1GB) spanning multiple MTRRs. qemu takes care to use gigabyte-alignment for guest RAM for performance reasons. Unless you are explicitly creating something unusual the memory layout below 4G is 2G RAM + 2G MMIO (q35 machine type) or 3G RAM + 1G MMIO (pc machine type). edk2 creates mtrr uncachable entries for the mmio regions (both 32bit and 64bit window). On q35 it looks like this: reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable reg01: base=0x7000000000 (458752MB), size=65536MB, count=1: uncachable Both are gigabyte-aligned and are a multiple of gigabytes in size, so you simply can't create gigabyte page table entries crossing mtrr entry borders. That's relatively recent change though, q35 used to be different, see commit e4b3fd905a17 ("OvmfPkg/PlatformInitLib: simplify mtrr setup") > While I don't expect my comment to be a blocker (particularly as other > OVMF platforms are already using them), I think it's probably a good > idea to let you know. Yes, thanks, sure good to know. But I don't expect that being a problem. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105109): https://edk2.groups.io/g/devel/message/105109 Mute This Topic: https://groups.io/mt/98944976/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2023 Red Hat, Inc.