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.