Re: [PATCH v4 03/23] KVM: PPC: Flush/zap all memslots on kvm_arch_flush_shadow_all()

On Wed, Nov 04, 2026, Narayana Murty N wrote:

Hi Sean,

On 31/10/26 2:50 AM, Sean Christopherson wrote:

quoted

Flush/zap every memslot in kvm_arch_flush_shadow_all(), i.e. when the
owning userspace process is exiting, as KVM must ensure all associated
memory is unmapped from the guest.

Cc: <redacted>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
  arch/powerpc/include/asm/kvm_host.h |  1 -
  arch/powerpc/kvm/powerpc.c          | 11 +++++++++++
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 708a32f89776..50a42f80e5f1 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h

@@ -910,7 +910,6 @@ struct kvm_vcpu_arch {
  #define __KVM_HAVE_CREATE_DEVICE
  static inline void kvm_arch_memslots_updated(struct kvm *kvm, u64 gen) {}
-static inline void kvm_arch_flush_shadow_all(struct kvm *kvm) {}
  static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
  static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 9194cf492d1c..9e9d0865c2f6 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c

@@ -764,6 +764,17 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
  	kvmppc_core_commit_memory_region(kvm, old, new, change);
  }
+void kvm_arch_flush_shadow_all(struct kvm *kvm)
+{
+	struct kvm_memory_slot *slot;
+	struct kvm_memslots *slots;
+	int bkt;
+
+	slots = kvm_memslots(kvm);
+	kvm_for_each_memslot(slot, bkt, slots)
+		kvmppc_core_flush_memslot(kvm, slot);

For Book3S HV/hash, I am not sure the existing flush_memslot helper can
be used on an active memslot like this.

The normal memslot invalidation path seems to deliberately establish
the opposite ordering.  kvm_invalidate_memslot() first installs an
INVALID slot and makes it active:

	invalid_slot->flags |= KVM_MEMSLOT_INVALID;
	kvm_replace_memslot(kvm, old, invalid_slot);
	kvm_swap_active_memslots(kvm, old->as_id);
and only then does kvm_arch_flush_shadow_memslot(kvm, old);.

The comment there explicitly states:
/*
 * From this point no new shadow pages pointing to a deleted,
 * or moved, memslot will be created.
 */

Similarly, kvmppc_core_flush_memslot_hv() in
arch/powerpc/kvm/book3s_64_mmu_hv.c relies on the memslot already being
invalid when testing KVMPPC_RMAP_PRESENT without locking, as no new HPTEs
can be created.

However, kvm_arch_flush_shadow_all() in arch/powerpc/kvm/powerpc.c now
invokes the same helper while walking active memslots.

Is there any serialization in the mmu_notifier.release() path that provides
the same guarantee against new HPTE creation?

There can't be any outstanding *usable* references to vCPUs at this point.
mmu_notifier.release() is only invoked if the process is exiting or the VM is
dying (which requires the associated file to have been released).

If the process is existing, KVM_RUN (and most ioctls) are unreachable due to the
"dev->kvm->mm != current->mm" checks.  Not to mention that if the process is
exiting, doing anything with a memslot is completely broken because it means
things like hva_to_pfn() are somehow operating on the wrong mm.

If the VM is dying, there can't be any references to vCPU FDs, because each vCPU
holds a reference to the VM.

Otherwise, couldn't an H_ENTER or fault path create a new HPTE while the
rmap is being scanned, or after it has already been examined?