Re: [PATCH v5 0/7] KVM: arm64: pKVM stage-2 mapping and memcache fixes

[Bradley Morgan]

On July 17, 2026 2:03:10 PM GMT+01:00, Fuad Tabba <fuad.tabba@xxxxxxxxx>
wrote:
>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@xxxxxxxxx
>[2] https://lore.kernel.org/r/20260624160028.15591-1-include@xxxxxxxxx
>[3] https://lore.kernel.org/r/86qzllpy1g.wl-maz@xxxxxxxxxx
>[4]
>https://lore.kernel.org/all/20260623161545.EA08E1F000E9@xxxxxxxxxxxxxxx/
>[5]
>https://lore.kernel.org/all/20260623165634.699011F000E9@xxxxxxxxxxxxxxx/

Whole series


PKVM.c/.h
Tested-by: Bradley Morgan <include@xxxxxxxxx> # On pixel 7, Android 17 CP2A.260705.006

Test: Tested-by: Bradley Morgan <include@xxxxxxxxx> # On QEMU arm64 host
 

Thanks!