Re: [PATCH v3 2/3] KVM: Skip invoking shared memory handler for entirely private GFN ranges

[Yan Zhao <yan.y.zhao@intel.com>]

On Mon, Aug 25, 2025 at 02:05:22PM -0700, Sean Christopherson wrote:
> On Fri, Aug 22, 2025, Yan Zhao wrote:
> > When a GFN range is entirely private, it's unnecessary for
> > kvm_handle_hva_range() to invoke handlers for the GFN range, because
> > 1) the gfn_range.attr_filter for the handler is KVM_FILTER_SHARED, which
> >    is for shared mappings only;
> > 2) KVM has already zapped all shared mappings before setting the memory
> >    attribute to private.
> > 
> > This can avoid unnecessary zaps on private mappings for VMs of type
> > KVM_X86_SW_PROTECTED_VM, e.g., during auto numa balancing scans of VMAs.
> 
> This feels like the wrong place to try and optimize spurious zaps.  x86 should
> be skipping SPTEs that don't match.  For KVM_X86_SW_PROTECTED_VM, I don't think
> we care about spurious zpas, because that's a testing-only type that doesn't have
> line of sight to be being a "real" type.
> 
> For SNP, we might care?  But actually zapping private SPTEs would require
> userspace to retain the shared mappings across a transition, _and_ be running
> NUMA autobalancing in the first place.  If someone actually cares about optimizing
Hmm, "running NUMA autobalancing" + "madvise(MADV_DONTNEED)" can still trigger
the spurious zaps.

task_numa_work  ==> found a VMA
  change_prot_numa
    change_protection
      change_pud_range ==> mmu_notifier_invalidate_range_start() if !pud_none()
 
Let me use munmap() in patch 3 to guard againt spurious zap then.

> this scenario, KVM x86 could track private SPTEs via a software-available bit.
> 
> We also want to move away from KVM_MEMORY_ATTRIBUTE_PRIVATE and instead track
> private vs. shared in the gmem instance.
>
> So I'm inclined to skip this...
Fair enough. Thank you for the detailed explanation!