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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aK1ZYeGaInCaixnw@yzhao56-desk.sh.intel.com>
Date: Tue, 26 Aug 2025 14:51:13 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: <pbonzini@...hat.com>, <peterx@...hat.com>, <rick.p.edgecombe@...el.com>,
	<linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] KVM: Skip invoking shared memory handler for
 entirely private GFN ranges

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!