From: Fuad Tabba <fuad.tabba@linux.dev>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>
Cc: Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Shuah Khan <shuah@kernel.org>,
Quentin Perret <qperret@google.com>,
Vincent Donnefort <vdonnefort@google.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Gavin Shan <gshan@redhat.com>, Dev Jain <dev.jain@arm.com>,
Bradley Morgan <include@grrlz.net>, Fuad Tabba <tabba@google.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/7] KVM: arm64: pKVM stage-2 mapping and memcache fixes
Date: Fri, 17 Jul 2026 14:03:10 +0100 [thread overview]
Message-ID: <20260717130317.1953574-1-fuad.tabba@linux.dev> (raw)
Hi folks,
Changes since v4 [1]:
- Restored the permission-fault and dirty-logging memcache top-ups
that v4 dropped. Both fix real bugs.
- Patch 1 uses the anonymous bitfield encoding rather than the
open-coded mask and helpers. (Marc)
- Reshaped the permission-fault top-up to stage the full memcache
under pKVM, not just the mapping object. The object-only form still
returned -ENOMEM and tripped a WARN under the hypervisor's
unconditional min-pages check.
- Re-scoped the dirty-logging top-up to its generic, non-pKVM failure
mode, now that the permission-fault patch covers pKVM.
- Added three adjacent fixes found while going through the series, and
a selftest for the block transitions.
- Patches 1 and 3 keep Bradley's Signed-off-by from v3; my changes
to each are noted in a [tabba: ...] line.
I picked this up while reviewing Bradley's "mapping cache" series [2]:
v4 dropped two fixes from v3 that address real bugs, so I've collected
the three fixes back together, reshaped patch 1 per Marc's review [3],
added a few adjacent fixes I found along the way and a selftest, and am
reposting as v5.
Most of the fixes are in the pKVM stage-2 walker. On a pKVM host a
non-protected guest's stage-2 faults go through pkvm_pgtable_*(), which
diverges from the generic walker in several ways that are bugs: cache
maintenance on non-cacheable mappings (patch 1), a missing memcache
top-up on permission faults that under pKVM still allocate (patch 2), a
full flush walk on FWB hardware (patch 4), a WARN on a guest-reachable
map failure (patch 5), and an eager-split capability whose pKVM backend
is only a stub (patch 6). These affect non-protected guests only, since
dispatch and memcache selection key on the host-global pKVM mode, and
protected guests take no permission faults.
Patch 3 is not pKVM-specific. During dirty logging a non-write
permission fault, an instruction fetch, still needs a page-table page
to split a block, but the memcache top-up is gated on write faults.
That fault path is generic, so the fix is too.
The two memcache top-ups came from sashiko review-bot findings [4][5],
and both check out against the code.
The series is structured as follows:
1: Skip cache maintenance for non-cacheable mappings.
2-3: Top up the memcache for the permission and dirty-logging faults
that force stage-2 block transitions.
4-6: Adjacent pkvm_pgtable_*() fixes: FWB flush early-out, drop a
spurious map WARN, and gate the eager-split capability.
7: Selftest for the block-collapse and block-split transitions.
Testing: the selftest in patch 7 covers the two dirty-logging block
transitions (page->block collapse and block->page split) that patch 2
stages; on the base kernel the collapse oopses the host in
pkvm_pgtable_stage2_map() with a NULL dereference under mmu_lock, and
with the series applied it passes. It is a standalone test rather than
an extension of kvm_page_table_test, whose default anonymous-4K backing
forms no huge-page blocks, so an automated run never exercises these
transitions, and whose worker/stage harness does not fit the multi-stage
logging sequence. Run it with 2M hugepages
reserved and, for the split half, on a CPU with CTR_EL0.DIC == 0 (e.g.
-cpu cortex-a710 under QEMU); it self-skips those otherwise. It also
passes on a non-pKVM host (VHE and nVHE), where patch 3's generic change
applies. The other fixes are not exercised by the selftest and rest on
the analysis in their commit messages: patch 3's fault path is generic
and non-pKVM (under pKVM patch 2 already tops it up, and its failure is
a WARN_ON(!nobjs) in kvm_mmu_memory_cache_alloc(), not a KVM_RUN error),
and patches 1 and 4-6 each need a specific pKVM configuration to hit.
Based on Linux v7.2-rc3 (a13c140cc289).
Cheers,
/fuad
[1] https://lore.kernel.org/r/20260701192428.17430-1-include@grrlz.net
[2] https://lore.kernel.org/r/20260624160028.15591-1-include@grrlz.net
[3] https://lore.kernel.org/r/86qzllpy1g.wl-maz@kernel.org
[4] https://lore.kernel.org/all/20260623161545.EA08E1F000E9@smtp.kernel.org/
[5] https://lore.kernel.org/all/20260623165634.699011F000E9@smtp.kernel.org/
Bradley Morgan (2):
KVM: arm64: Skip cache maintenance for non-cacheable pKVM mappings
KVM: arm64: Top up stage-2 memcache for dirty logging faults
Fuad Tabba (5):
KVM: arm64: Top up the memcache for pKVM permission faults
KVM: arm64: Skip pKVM stage-2 flush when FWB is enabled
KVM: arm64: Don't WARN on pKVM stage-2 map failures
KVM: arm64: Don't advertise eager page splitting under pKVM
KVM: arm64: selftests: Add stage-2 block transition test
arch/arm64/include/asm/kvm_pkvm.h | 8 +-
arch/arm64/kvm/mmu.c | 9 +-
arch/arm64/kvm/pkvm.c | 21 +-
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../kvm/arm64/stage2_block_transitions.c | 226 ++++++++++++++++++
5 files changed, 254 insertions(+), 11 deletions(-)
create mode 100644 tools/testing/selftests/kvm/arm64/stage2_block_transitions.c
base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
--
2.39.5
next reply other threads:[~2026-07-17 13:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 13:03 Fuad Tabba [this message]
2026-07-17 13:03 ` [PATCH v5 1/7] KVM: arm64: Skip cache maintenance for non-cacheable pKVM mappings Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 2/7] KVM: arm64: Top up the memcache for pKVM permission faults Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 3/7] KVM: arm64: Top up stage-2 memcache for dirty logging faults Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 4/7] KVM: arm64: Skip pKVM stage-2 flush when FWB is enabled Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 5/7] KVM: arm64: Don't WARN on pKVM stage-2 map failures Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 6/7] KVM: arm64: Don't advertise eager page splitting under pKVM Fuad Tabba
2026-07-17 13:03 ` [PATCH v5 7/7] KVM: arm64: selftests: Add stage-2 block transition test Fuad Tabba
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=20260717130317.1953574-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dev.jain@arm.com \
--cc=gshan@redhat.com \
--cc=include@grrlz.net \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=shuah@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox