Re: [PATCH v5 0/7] Lazily allocate memslot rmaps

From: Paolo Bonzini
Date: Mon May 24 2021 - 08:44:05 EST

On 18/05/21 19:34, Ben Gardon wrote:
This series enables KVM to save memory when using the TDP MMU by waiting
to allocate memslot rmaps until they are needed. To do this, KVM tracks
whether or not a shadow root has been allocated. In order to get away
with not allocating the rmaps, KVM must also be sure to skip operations
which iterate over the rmaps. If the TDP MMU is in use and we have not
allocated a shadow root, these operations would essentially be op-ops
anyway. Skipping the rmap operations has a secondary benefit of avoiding
acquiring the MMU lock in write mode in many cases, substantially
reducing MMU lock contention.

This series was tested on an Intel Skylake machine. With the TDP MMU off
and on, this introduced no new failures on kvm-unit-tests or KVM selftests.

Incorporated feedback from Paolo and Sean
Replaced the memslot_assignment_lock with slots_arch_lock, which
has a larger critical section.

Removed shadow_mmu_active as suggested by Sean
Removed everything except adding a return value to
kvm_mmu_init_tdp_mmu from patch 1 of v2
Added RCU protection and better memory ordering for installing the
memslot rmaps as suggested by Paolo
Reordered most of the patches

Renamed functions to allocate and free memslots based on feedback
from David.
Eliminated the goto in memslot_rmap_alloc, as David suggested.
Eliminated kvm_memslots_have_rmaps and updated comments on uses of
memslots_have_rmaps. Suggested by Paolo.
Changed the description on patch 7 to one Paolo suggested.
Collected Reviewed-by tags from David.
Dropped the patch to add RCU notations to rmap accesses.

Responding to comments from Sean.
Improved comments
Swapped args to kvm_copy_memslots to match memcpy
Fixed some line wrap and declaration style issues
No longer check if memslots have rmaps before operations which
iterate through active_mmu_pages
Re-added the kvm_memslots_have_rmaps helper
Fixed a couple missing unlocks for the slots_arch_lock

Queued (with minor conflicts), thanks!