From: Mostafa Saleh <smostafa@google.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: xuheng@cs.columbia.edu, Marc Zyngier <maz@kernel.org>,
Oliver Upton <oupton@kernel.org>,
Quentin Perret <qperret@google.com>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] KVM: arm64: Compute hyp early-allocation and pool sizes in 64 bits
Date: Fri, 6 Nov 2026 14:02:40 +0000 [thread overview]
Message-ID: <au3eALuLVKZ1WXhp@google.com> (raw)
In-Reply-To: <CA+EHjTxXpA6sCrSmwRJBA=YKGfNP4zs-THhheRHTaq2BfYY-Lw@mail.gmail.com>
On Fri, Nov 06, 2026 at 11:31:57AM +0000, Fuad Tabba wrote:
> Hi Xuheng,
>
> On Thu, 05 Nov 2026 22:59:48 +0000, Xuheng Li <xuheng@cs.columbia.edu> wrote:
> > hyp_early_alloc_contig() and hyp_pool_init() both take a page count as
> > an unsigned int and compute the size in bytes as nr_pages << PAGE_SHIFT
> > in 32 bits. For 4 GiB or more (nr_pages >= 2^20 with 4 KiB pages) the
> > shift overflows.
>
> Mostafa (Cc'd) posted a fix for the same truncation in July [1],
> widening the parameters to unsigned long instead. Would you be OK
> picking up his patch for v3, keeping him as the author and your
> description and tags?
>
I was preparing v3 anyway, I can post it today.
Thanks,
Mostafa
> > Two of the regions that pKVM carves out at boot are sized from the
> > amount of memory: hyp_s1_pgtable_pages() for the hyp page tables (hpool)
> > and host_s2_pgtable_pages() for the host stage-2 pool both provision
> > page-granular tables for all of memory, about one page per 2 MiB of
> > RAM, so they reach 4 GiB on a machine with about 2 TiB of RAM. Arm
> > systems of that size exist, for example AWS Graviton4 x8g.metal-48xl
> > instances (3 TiB) and Ampere Altra Max servers (up to 4 TiB per
> > socket).
>
> Could you also list the hyp vmemmap here? It's sized the same way and
> overflows at 2 TiB too.
>
> > On such a machine, divide_memory_pool() gets a truncated hyp page-table
> > region from hyp_early_alloc_contig(), so the host stage-2 region and the
> > FF-A proxy pages that follow it start inside the range that hpool will
> > own. hyp_pool_init() then attaches all nr_pages pages of each pool to
> > its free lists, so hpool and host_s2_pool share pages and the same page
> > can be handed out twice, for example as a hyp stage-1 table and as a
> > host stage-2 table. hyp_pool_init() also derives range_end and
> > max_order from the truncated size, so most of each pool is treated as
> > external order-0 pages; on a host whose IPA size makes the host stage-2
> > PGD a multi-page allocation (for example a 42-bit PARange), that
> > allocation fails and host_s2_zalloc_pages_exact() uses the NULL result.
>
> Could you describe here what actually happens? I think pKVM init fails
> before any page is handed out twice. Just below 2 TiB, hyp_pool_init()
> for host_s2_pool hits the BUG_ON() in hyp_set_page_refcounted() on
> hpool's page-table pages, and from 2 TiB up hyp_back_vmemmap() zeroes
> the new hyp page tables while they're being built.
>
> Cheers,
> /fuad
>
> [1] https://lore.kernel.org/all/20260715150125.2798116-1-smostafa@google.com/
next prev parent reply other threads:[~2026-11-06 14:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 22:59 [PATCH v2 0/3] KVM: arm64: Fix the hyp pool size on large machines, plus two hardening patches Xuheng Li
2026-11-05 22:59 ` Xuheng Li via B4 Relay
2026-11-05 22:59 ` [PATCH v2 1/3] KVM: arm64: Compute hyp early-allocation and pool sizes in 64 bits Xuheng Li
2026-11-05 22:59 ` Xuheng Li via B4 Relay
2026-11-06 11:31 ` Fuad Tabba
2026-11-06 14:02 ` Mostafa Saleh [this message]
2026-11-06 14:31 ` Xuheng Li
2026-11-05 22:59 ` [PATCH v2 2/3] KVM: arm64: Check the host stage-2 PGD allocation for NULL Xuheng Li
2026-11-05 22:59 ` Xuheng Li via B4 Relay
2026-11-06 11:39 ` Fuad Tabba
2026-11-06 14:31 ` Xuheng Li
2026-11-05 22:59 ` [PATCH v2 3/3] KVM: arm64: Don't replace a valid hyp block mapping with a table Xuheng Li
2026-11-05 22:59 ` Xuheng Li via B4 Relay
2026-11-06 12:03 ` Fuad Tabba
2026-11-06 14:33 ` Vincent Donnefort
2026-11-06 14:33 ` Xuheng Li
2026-11-06 14:34 ` Fuad Tabba
2026-11-06 17:17 ` Xuheng Li
2026-11-06 18:53 ` Vincent Donnefort
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=au3eALuLVKZ1WXhp@google.com \
--to=smostafa@google.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=xuheng@cs.columbia.edu \
--cc=yuzenghui@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.