All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei-Lin Chang <weilin.chang@arm.com>
To: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oupton@kernel.org>, Fuad Tabba <tabba@google.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>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Dev Jain <dev.jain@arm.com>, Ard Biesheuvel <ardb@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Vincent Donnefort <vdonnefort@google.com>,
	Sebastian Ene <sebastianene@google.com>,
	Wei-Lin Chang <weilin.chang@arm.com>
Subject: [PATCH v3 0/2] arm64: ptdump flush fixes
Date: Fri, 14 Aug 2026 23:24:56 +0100	[thread overview]
Message-ID: <20260814222458.584906-1-weilin.chang@arm.com> (raw)

Hi,

This series fixes two problems around ptdumps:

1. note_page_flush(), which flushes out the last row of ptdumps, does
   not account for address spaces that have IA < 64. Other than making
   the last region extremely huge, the attributes of the last region
   within the address spaces appear to extend all the way to 1 << 64.

2. KVM/arm64's stage-2 ptdump missed calling note_page_flush().

To address Will's comment [1], I have created an end_address field for
struct ptdump_pg_state, and initialized it with the end address of the
ptdumps. It follows the same convention as the last range->end:
exclusive end, except for the case where the address space ends at
1 << 64. In that case it is set as ULONG_MAX.

Caching the end address avoids duplicating the range iteration in
note_page_flush(), at the cost of duplicating state in ptdump_pg_state.

Series is based on v7.2-rc5.

* Changes from v2:

  - Instead of scanning ptdump_state.range[] to find the end address,
    cache the end address in a new field end_address when we initialize
    struct ptdump_pg_state.

  - Adjust KVM's struct ptdump_pg_state initialization so it uses
    end_address instead of ptdump_state.range[].

  - Collected Reviewed-by and Tested-by from Dev, thanks!

  - v2: https://lore.kernel.org/r/20260724185431.2990395-1-weilin.chang@arm.com/

* Changes from v1:

  - Instead of manually calling note_page() for flushing, fix
    note_page_flush() so that it ends the ptdump at the end of the
    address space.

  - Changed the start address of the second marker to ULONG_MAX for KVM
    ptdump, so we don't output extra marker names, and advance past the
    end of the marker array.

  - v1: https://lore.kernel.org/r/20260717231233.2299068-1-weilin.chang@arm.com/

Thanks!

[1]: https://lore.kernel.org/r/anXFo-igVdqrCogQ@willie-the-truck/

Wei-Lin Chang (2):
  arm64: ptdump: Make note_page_flush() range aware
  KVM: arm64: ptdump: Flush the last region

 arch/arm64/include/asm/ptdump.h |  2 ++
 arch/arm64/kvm/ptdump.c         | 11 +++++++----
 arch/arm64/mm/ptdump.c          | 14 +++++++++++++-
 3 files changed, 22 insertions(+), 5 deletions(-)

-- 
2.43.0


             reply	other threads:[~2026-08-14 22:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-14 22:24 Wei-Lin Chang [this message]
2026-08-14 22:24 ` [PATCH v3 1/2] arm64: ptdump: Make note_page_flush() range aware Wei-Lin Chang
2026-08-15 11:28   ` Marc Zyngier
2026-08-15 23:16     ` Wei-Lin Chang
2026-08-14 22:24 ` [PATCH v3 2/2] KVM: arm64: ptdump: Flush the last region Wei-Lin Chang
2026-08-23 10:13 ` [PATCH v3 0/2] arm64: ptdump flush fixes Marc Zyngier
2026-08-24 13:30   ` Will Deacon
2026-08-24 16:01 ` Will Deacon

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=20260814222458.584906-1-weilin.chang@arm.com \
    --to=weilin.chang@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --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=matt@codeblueprint.co.uk \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=sebastianene@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vdonnefort@google.com \
    --cc=will@kernel.org \
    --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.