From: "Denis V. Lunev" <den@virtuozzo.com>
To: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>,
svt-core@virtuozzo.com
Cc: den@openvz.org
Subject: Re: [PATCH edk2 hci-8.1] OvmfPkg/PlatformInitLib: switch to 5-level paging only above 16TB #VSTOR-152672 #VSTOR-152405
Date: Mon, 2 Nov 2026 16:44:22 +0100 [thread overview]
Message-ID: <524478b7-a237-4e51-bf24-6b65a8ffe9bf@virtuozzo.com> (raw)
In-Reply-To: <20261102152520.61693-1-andrey.drobyshev@virtuozzo.com>
On 11/2/26 16:25, Andrey Drobyshev wrote:
> With PcdUse5LevelPageTable the 64-bit PEI decides per guest whether to
> hand the OS over in 4- or 5-level paging mode. Without a fw_cfg
> override it uses 5-level paging as soon as the guest address space
> (RAM plus the memory hotplug window) reaches 1TB.
>
> That threshold is too low for us:
>
> * 4-level firmware paging already covers 64TB of address space, so
> 5-level paging below that buys nothing and only changes what the OS
> sees at ExitBootServices;
> * on Windows that means booting the LA57 kernel (ntkrla57.exe), which
> bugchecks on AMD guests exposed to the ARCH_CAPABILITIES MSR
> (VSTOR-152405) and breaks Windows Setup. QEMU since the commit
> 7fc0e1c9f577 ("i386: hide la57 at fresh start on vz machine types
> that show ARCH_CAPABILITIES #VSTOR-152405") now hides la57 on the
> VZ machine types that expose the MSR, but the firmware shouldn't
> depend on that.
>
> Raise the threshold to 16TB. Ordinary guests, including those with a
> large hotplug window, stay in 4-level paging.
>
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> ---
> OvmfPkg/Library/PlatformInitLib/MemDetect.c | 6 +++---
> OvmfPkg/RUNTIME_CONFIG.md | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index 937e2b77a5..7220db8ef9 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -967,7 +967,7 @@ Switch4Level (
> Should that not be the case the function checks the size of the address space
>
> needed, which is the RAM installed plus fw_cfg reservations. The downgrade
>
> to 4-level paging will happen for small guests where the address space needed
>
> - is lower than 1TB.
>
> + is lower than 16TB.
>
>
>
>
>
> This function will also log the paging level used and the reason for that.
>
> @@ -1002,9 +1002,9 @@ PlatformSetupPagingLevel (
> );
>
> switch (Status) {
>
> case EFI_NOT_FOUND:
>
> - if (PlatformInfoHob->FirstNonAddress < (1ll << 40)) {
>
> + if (PlatformInfoHob->FirstNonAddress < (1ll << 44)) {
>
> //
>
> - // If the highest address actually used is below 1TB switch back into
>
> + // If the highest address actually used is below 16TB switch back into
>
> // 4-level paging mode for better compatibility with older guests.
>
> //
>
> DEBUG ((DEBUG_INFO, "%a: using 4-level paging (default for small guest)\n", __func__));
>
> diff --git a/OvmfPkg/RUNTIME_CONFIG.md b/OvmfPkg/RUNTIME_CONFIG.md
> index b75a5dacad..3bef1e6e4a 100644
> --- a/OvmfPkg/RUNTIME_CONFIG.md
> +++ b/OvmfPkg/RUNTIME_CONFIG.md
> @@ -228,7 +228,7 @@ paging levels are better for compatibility, not all OSes can handle
> levels are better for huge VMs, the address space managed by OVMF can
>
> be larger.
>
>
>
> -Default: Use 5-level paging in case more than 1TB of memory is
>
> +Default: Use 5-level paging in case more than 16TB of memory is
>
> present, 4-level paging otherwise.
>
>
>
> Usage:
>
Reviewed-by: Denis V. Lunev <den@openvz.org>
prev parent reply other threads:[~2026-11-02 15:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 15:25 Andrey Drobyshev
2026-11-02 15:44 ` Denis V. Lunev [this message]
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-all 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=524478b7-a237-4e51-bf24-6b65a8ffe9bf@virtuozzo.com \
--to=den@virtuozzo.com \
--cc=andrey.drobyshev@virtuozzo.com \
--cc=den@openvz.org \
--cc=svt-core@virtuozzo.com \
/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