From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7419B25E813; Sun, 24 Aug 2025 08:55:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756025741; cv=none; b=mGDcISB5LwmXpJCIwKTj5tN49NGfOyWIA5HTWvu3UNrelWBBkcdCdcZptqPbEnCx4Jf0quf7pLMSLNXDWmokuejQOE01n+gOYfYquFqwTtp5614yBiK1kry9xns2y3+htaUFC01O7fSCuD010cYUtCo1aUzH+p22BrAXFzmHDfQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756025741; c=relaxed/simple; bh=3efWoqKGeWKkhZdCmvOAtelROBxMcZQovbTe+Bsz4Qo=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Y2s+mSGOfoebjavwRALUcFW3Jnd0Y7AIRMcERD6Lj28E4wXE7+HyXDXTL5MxUHoJ4kWAACSmFa/JdfQCcRgCNl+NsqbM/0ZrYKRXQVSdjhJzNEoyuQ+QZLxK8hLXbiazwHP8+KtTHiWtp9B611mBQCfPxXcHcdqkQfuHdCSr4Q0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c0fc+Imn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c0fc+Imn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 344FCC116B1; Sun, 24 Aug 2025 08:55:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756025741; bh=3efWoqKGeWKkhZdCmvOAtelROBxMcZQovbTe+Bsz4Qo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c0fc+ImnS9/BDevSzy+t+aRAEDOYCniaBkwi+IW58oy+IcTfmR81WTqGPM9Cpat8E dZAfuYb7yESRUBrATeBON5H6c8cjU6Zi2LVycUupFtpbgdy4Zo0+dz79cnxU3lkNnh 883c6cMkhi40MH2YimoXW8ymsup5QT4Vbl6lDMh+ss6yaFa7/CWGll5eWqIXIE6TNh aIpryI0WHxHwuIAZjNgo5u2oIIMFPa+vyYc/qkq1NGrF9Dl2wFgnWPlUdZa3Msteco kGgVI6VvU8gB78ERpXSZI7UcFQYCDbChtC1hFyAYo0atd10lGNPoHeFkwxoigQ0HqL me7zEt6/mQaiA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uq6Vm-00AWlW-E3; Sun, 24 Aug 2025 09:55:38 +0100 Date: Sun, 24 Aug 2025 09:55:34 +0100 Message-ID: <874itx14l5.wl-maz@kernel.org> From: Marc Zyngier To: Sam Edwards Cc: Ard Biesheuvel , Catalin Marinas , Will Deacon , Andrew Morton , Anshuman Khandual , Ryan Roberts , Baruch Siach , Kevin Brodsky , Joey Gouly , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] arm64/boot: Zero-initialize idmap PGDs before use In-Reply-To: References: <20250822041526.467434-1-CFSworks@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: cfsworks@gmail.com, ardb@kernel.org, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, anshuman.khandual@arm.com, ryan.roberts@arm.com, baruch@tkos.co.il, kevin.brodsky@arm.com, joey.gouly@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Sam, On Sun, 24 Aug 2025 04:05:05 +0100, Sam Edwards wrote: >=20 > On Sat, Aug 23, 2025 at 5:29=E2=80=AFPM Ard Biesheuvel = wrote: > > [...] > > Under which conditions would PGD_SIZE assume a value greater than PAGE_= SIZE? >=20 > I might be doing my math wrong, but wouldn't 52-bit VA with 4K > granules and 5 levels result in this? No. 52bit VA at 4kB granule results in levels 0-3 each resolving 9 bits, and level -1 resolving 4 bits. That's a total of 40 bits, plus the 12 bits coming directly from the VA making for the expected 52. > Each PTE represents 4K of virtual memory, so covers VA bits [11:0] > (this is level 3) That's where you got it wrong. The architecture is pretty clear that each level resolves PAGE_SHIFT-3 bits, hence the computation above. The bottom PAGE_SHIFT bits are directly extracted from the VA, without any translation. > Each PMD has 512 PTEs, the index of which covers VA bits [20:12] (this > is level 2) > Each PUD references 512 PMDs, the index covering VA [29:21] (this is leve= l 1) > Each P4D references 512 PUDs, indexed by VA [38:30] (this is level 0) > The PGD, at level -1, therefore has to cover VA bits [51:39], which > means it has a 13-bit index: 8192 entries of 8 bytes each would make > it 16 pages in size. > > > Note that at stage 1, arm64 does not support page table concatenation, > > and so the root page table is never larger than a page. >=20 > Doesn't PGD_SIZE refer to the size used for userspace PGDs after the > boot progresses beyond stage 1? (What do you mean by "never" here? > "Under no circumstances is it larger than a page at stage 1"? Or > "during the entire lifecycle of the system, there is no time at which > it's larger than a page"?) Never, ever, is a S1 table bigger than a page. This concept doesn't exist in the architecture. Only S2 tables can use concatenation at the top-most level, for up to 16 pages (in order to skip a level when possible). The top-level can be smaller than a page, with some alignment constraints, but that's about the only degree of freedom you have for S1 page tables. Thanks, M. --=20 Jazz isn't dead. It just smells funny.