Re: [RFC PATCH 0/2] KVM: arm64: nv: Skip empty spans when unmapping a shadow S2

[Oliver Upton]

Hi,

On Mon, Nov 09, 2026 at 06:34:29PM +0500, Haseeb Ashraf wrote:
> Emulating TLBI VMALLS12E1IS, emulating TLBI ALLE1IS and recycling a
> shadow stage-2 all unmap the whole nested IPA space in chunks of the
> largest block size, even when the table is empty. With a 48-bit PARange
> and 4kB pages that is 262144 unmap calls per shadow MMU, each ending in a
> range TLBI when FEAT_TLBIRANGE and FWB are available.
> 
> Measured cost: one full-range unmap of a shadow MMU takes 0.87-1.06 s on
> AmpereOne (Xen on KVM, 4kB pages, function_graph). On Graviton4
> (Xen-on-KVM, 48-bit IPA) a single VMALLS12E1IS trap took 1.46-9.50 s over
> twelve samples (median 3.09 s), all of it in stage2_apply_range().
> 
> Patch 1 adds kvm_stage2_unmap_all(), which skips spans covered by a zero
> descriptor at least as large as an unmap chunk, keeps the tracked unmap
> for everything else, removes the guest stage-2 records of skipped spans,
> and ends with the VMID-wide TLBI that VMALLS12E1IS requires. It converts
> the VMALLS12E1IS handler. Patch 2 converts kvm_nested_s2_unmap() (ALLE1IS,
> whole-VM unmap) and the pending unmap of a recycled shadow MMU.
> 
> The series is based on master, which already has the guest stage-2
> tracking. It overlaps with the unmerged kvm-arm64/unmap-vmall work, which
> defines a kvm_stage2_unmap_all() with the same name and signature; if that
> lands first, patch 1 becomes "skip empty spans in kvm_stage2_unmap_all()".
> As far as I can tell, that WIP helper does not touch the guest stage-2
> tracking records, which this series does.

Basing your series on a random, out-of-date version of a patch series is
never OK.

The direction we're taking with that series is to have the inner walk
report the next IPA to visit to the outer loop, this should do the same.

https://lore.kernel.org/kvmarm/20261106133000.453240-2-fuad.tabba@xxxxxxxxx/

Thanks,
Oliver