From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 701CA352C2C; Sat, 15 Aug 2026 11:28:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786793308; cv=none; b=bVtPimvkOW4/pOMfy4OLU5d/93nNLSm3nRr6p1H9NxWPXygyooXXccrKwT8KnFpP04BgrASm7y+hMW9veabhf4NEqj4Q2BrSHprKgAHE06Ou7slWETgLGbffu/vvGurh+98qRPkxQyFJ1f4tMvE+m+4I6GbKAninix3UiQdzxW0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786793308; c=relaxed/simple; bh=Rc8ksUJBgnHSXYYdtIFJILfkmQaRQ3ZySn9lwbhWTFA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=iNjKg9Cu3hsMwD40YA/CNHsg5CpQ5Rj0OwsTjxBuqn+HcUKZMpumfVhfeMSOmf1JfJvxfLSkKSAaZltu9nEYmJoEIZVPrW8sPuNPedjtQU5W6orGIaTHE12Bye78AF31i8Rx+hvo0Yj03h1oNZX6rpyhJ/RbvZUMsJsYfC87J4o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CRJRjVg3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CRJRjVg3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02FBC1F000E9; Sat, 15 Aug 2026 11:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786793307; bh=ugvf8a5SmwQNPVwzIXcq8c6ETBDk4V2dnKiIGUlaOno=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CRJRjVg3NUqrkqQiGfAVCAtwKQ5OuVVtQ+u+34yUYNcRErmuaTv/LFbD6Tea62s2m TtXf3fTfl1Zf/Sh242quswPihP6K5Qmc/lGTzySiRKtWlQfJXPYb/KDhVKPhxXvzld +KePBRCjBFmRux/wFxGEm8yRwh5xPjhQ3AKCqOs9IVWwmGYVGWvOGGhHbNHIuWdPOF C3jKKOfncFKFnp7z5G3Qh/3fXb6d2wyvFZQNIxH2tIoZ2nv9iabjRkSNy7x6NPz89i AECB7W2RA7fNfm9lPWyGV+xle+JB9kERgLDbiWb/X7XLVqLULvoRBoXI0PIkryvqcL kVLYVQ88BgtBQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wvCYq-0000000Fsrq-3AfX; Sat, 15 Aug 2026 11:28:24 +0000 Date: Sat, 15 Aug 2026 12:28:23 +0100 Message-ID: <86v79bzkq0.wl-maz@kernel.org> From: Marc Zyngier To: Wei-Lin Chang Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , "Mike Rapoport (Microsoft)" , Ryan Roberts , "David Hildenbrand (Arm)" , Anshuman Khandual , Dev Jain , Ard Biesheuvel , Mark Rutland , Matt Fleming , Vincent Donnefort , Sebastian Ene Subject: Re: [PATCH v3 1/2] arm64: ptdump: Make note_page_flush() range aware In-Reply-To: <20260814222458.584906-2-weilin.chang@arm.com> References: <20260814222458.584906-1-weilin.chang@arm.com> <20260814222458.584906-2-weilin.chang@arm.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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: weilin.chang@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, oupton@kernel.org, tabba@google.com, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, rppt@kernel.org, ryan.roberts@arm.com, david@kernel.org, anshuman.khandual@arm.com, dev.jain@arm.com, ardb@kernel.org, mark.rutland@arm.com, matt@codeblueprint.co.uk, vdonnefort@google.com, sebastianene@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 14 Aug 2026 23:24:57 +0100, Wei-Lin Chang wrote: > > note_page_flush() calls note_page() with addr == 0 and level == -1 to > dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around) > renders a huge region with enormous size for address spaces with > IA bits < 64. For example the stage-2 page tables and the EFI runtime > page table. > > More importantly, the last region of the address space and everything > after the address space up to 1 << 64 are merged into one row of > output. If the last region within the address space is valid, it will > appear to remain valid up to 1 << 64 with the same attributes. > > Currently only the EFI runtime ptdump is affected by this, but KVM will > soon fix its stage-2 ptdump by using note_page_flush(). Here is an > example of an EFI runtime ptdump (last row): > > 0x0000008000000000-0x0000000000000000 17179868672G PGD > > With this patch: > > 0x0000008000000000-0x0001000000000000 261632G PGD > > To fix this, cache the end address of a ptdump in ptdump_pg_state so > note_page_flush() can call the final note_page() with the correct end > address. > > Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") > Signed-off-by: Wei-Lin Chang > --- > arch/arm64/include/asm/ptdump.h | 2 ++ > arch/arm64/mm/ptdump.c | 14 +++++++++++++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h > index 5b374a6ab34a..1b743de7d89e 100644 > --- a/arch/arm64/include/asm/ptdump.h > +++ b/arch/arm64/include/asm/ptdump.h > @@ -52,6 +52,8 @@ struct ptdump_pg_state { > const struct addr_marker *marker; > const struct mm_struct *mm; > unsigned long start_address; > + /* exclusive end, ULONG_MAX represents an end at 1 << 64 */ > + unsigned long end_address; > int level; > ptval_t current_prot; > bool check_wx; > diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c > index 1c20144700d7..eab400e744d9 100644 > --- a/arch/arm64/mm/ptdump.c > +++ b/arch/arm64/mm/ptdump.c > @@ -278,9 +278,19 @@ void note_page_pgd(struct ptdump_state *pt_st, unsigned long addr, pgd_t pgd) > > void note_page_flush(struct ptdump_state *pt_st) > { > + struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump); > + unsigned long end = st->end_address; > pte_t pte_zero = {0}; > > - note_page(pt_st, 0, -1, pte_val(pte_zero)); > + /* > + * Address spaces that end at 1 << 64 have end_address == ULONG_MAX, > + * but note_page() expects the exclusive end. In this case adjust end > + * to the wraparound value 0. > + */ > + if (end == ULONG_MAX) > + end = 0; > + > + note_page(pt_st, end, -1, pte_val(pte_zero)); > } > > static void arm64_ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm) > @@ -303,6 +313,7 @@ void ptdump_walk(struct seq_file *s, struct ptdump_info *info) > .marker = info->markers, > .mm = info->mm, > .pg_level = &kernel_pg_levels[0], > + .end_address = end, > .level = -1, > .ptdump = { > .note_page_pte = note_page_pte, > @@ -344,6 +355,7 @@ bool ptdump_check_wx(void) > { -1, NULL}, > }, > .pg_level = &kernel_pg_levels[0], > + .end_address = ~0UL, nit: shouldn't this be ULONG_MAX instead? Yes, this is the same thing, but it doesn't hurt to match the documentation. Thanks, M. -- Without deviation from the norm, progress is not possible.