From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: devel@edk2.groups.io, kraxel@redhat.com
Cc: Jordan Justen <jordan.l.justen@intel.com>,
Oliver Steffen <osteffen@redhat.com>,
Pawel Polawski <ppolawsk@redhat.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jiewen Yao <jiewen.yao@intel.com>
Subject: Re: [edk2-devel] [PATCH 0/3] OvmfPkg: gigabyte page tweaks
Date: Thu, 18 May 2023 00:16:21 +0100 [thread overview]
Message-ID: <CAKbZUD0WE6nRv2bNwGN=LTo2e5qHek3vbE827DAm++g7ZZugjQ@mail.gmail.com> (raw)
In-Reply-To: <20230517102449.1334621-1-kraxel@redhat.com>
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
next prev parent reply other threads:[~2023-05-17 23:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 10:24 [PATCH 0/3] OvmfPkg: gigabyte page tweaks Gerd Hoffmann
2023-05-17 10:24 ` [PATCH 1/3] OvmfPkg/PlatformInitLib: check PcdUse1GPageTable Gerd Hoffmann
2023-05-22 10:37 ` Ard Biesheuvel
2023-05-22 11:18 ` Gerd Hoffmann
2023-05-17 10:24 ` [PATCH 2/3] OvmfPkg/OvmfPkgIa32X64: enable 1G pages Gerd Hoffmann
2023-05-17 10:24 ` [PATCH 3/3] OvmfPkg/MicrovmX64: " Gerd Hoffmann
2023-05-17 23:16 ` Pedro Falcato [this message]
2023-05-22 9:39 ` [edk2-devel] [PATCH 0/3] OvmfPkg: gigabyte page tweaks Gerd Hoffmann
2023-05-25 15:48 ` Ard Biesheuvel
2023-05-29 11:41 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKbZUD0WE6nRv2bNwGN=LTo2e5qHek3vbE827DAm++g7ZZugjQ@mail.gmail.com' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox