Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 May 2021 21:34:46 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Ben Gardon <bgardon@google.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, Peter Xu <peterx@redhat.com>,
        Peter Shier <pshier@google.com>,
        Peter Feiner <pfeiner@google.com>,
        Junaid Shahid <junaids@google.com>,
        Jim Mattson <jmattson@google.com>,
        Yulei Zhang <yulei.kernel@gmail.com>,
        Wanpeng Li <kernellwp@gmail.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Xiao Guangrong <xiaoguangrong.eric@gmail.com>
Subject: Re: [PATCH v2 00/13] More parallel operations for the TDP MMU
Message-ID: <YK6+9lmToiFTpvmq@google.com>
References: <20210401233736.638171-1-bgardon@google.com>
 <c630df18-c1af-8ece-37d2-3db5dc18ecc8@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c630df18-c1af-8ece-37d2-3db5dc18ecc8@redhat.com>
Precedence: bulk

On Fri, Apr 02, 2021, Paolo Bonzini wrote:
> On 02/04/21 01:37, Ben Gardon wrote:
> > Now that the TDP MMU is able to handle page faults in parallel, it's a
> > relatively small change to expand to other operations. This series allows
> > zapping a range of GFNs, reclaiming collapsible SPTEs (when disabling
> > dirty logging), and enabling dirty logging to all happen under the MMU
> > lock in read mode.
> > 
> > This is partly a cleanup + rewrite of the last few patches of the parallel
> > page faults series. I've incorporated feedback from Sean and Paolo, but
> > the patches have changed so much that I'm sending this as a separate
> > series.
> > 
> > Ran kvm-unit-tests + selftests on an SMP kernel + Intel Skylake, with the
> > TDP MMU enabled and disabled. This series introduces no new failures or
> > warnings.
> > 
> > I know this will conflict horribly with the patches from Sean's series
> > which were just queued, and I'll send a v2 to fix those conflicts +
> > address any feedback on this v1.
> > 
> > Changelog
> > v2:
> > --	Rebased patches on top of kvm/queue to incorporate Sean's recent
> > 	TLB flushing changes
> > --	Dropped patch 5: "KVM: x86/mmu: comment for_each_tdp_mmu_root
> > 	requires MMU write lock" as the following patch to protect the roots
> > 	list with RCU adds lockdep which makes the comment somewhat redundant.
> > 
> > Ben Gardon (13):
> >    KVM: x86/mmu: Re-add const qualifier in
> >      kvm_tdp_mmu_zap_collapsible_sptes
> >    KVM: x86/mmu: Move kvm_mmu_(get|put)_root to TDP MMU
> >    KVM: x86/mmu: use tdp_mmu_free_sp to free roots
> >    KVM: x86/mmu: Merge TDP MMU put and free root
> >    KVM: x86/mmu: Refactor yield safe root iterator
> >    KVM: x86/mmu: Make TDP MMU root refcount atomic
> >    KVM: x86/mmu: handle cmpxchg failure in kvm_tdp_mmu_get_root
> >    KVM: x86/mmu: Protect the tdp_mmu_roots list with RCU
> >    KVM: x86/mmu: Allow zap gfn range to operate under the mmu read lock
> >    KVM: x86/mmu: Allow zapping collapsible SPTEs to use MMU read lock
> >    KVM: x86/mmu: Allow enabling / disabling dirty logging under MMU read
> >      lock
> >    KVM: x86/mmu: Fast invalidation for TDP MMU
> >    KVM: x86/mmu: Tear down roots in fast invalidation thread
> > 
> >   arch/x86/include/asm/kvm_host.h |  21 +-
> >   arch/x86/kvm/mmu/mmu.c          | 115 +++++++---
> >   arch/x86/kvm/mmu/mmu_internal.h |  27 +--
> >   arch/x86/kvm/mmu/tdp_mmu.c      | 375 +++++++++++++++++++++++---------
> >   arch/x86/kvm/mmu/tdp_mmu.h      |  28 ++-
> >   include/linux/kvm_host.h        |   2 +-
> >   6 files changed, 407 insertions(+), 161 deletions(-)
> > 
> 
> Applied to kvm/mmu-notifier-queue, thanks.

What's the plan for kvm/mmu-notifier-queue?  More specifically, are the hashes
stable, i.e. will non-critical review feedback get squashed?  I was finally
getting around to reviewing this, but what's sitting in that branch doesn't
appear to be exactly what's posted here.  If the hashes are stable, I'll probably
test and review functionality, but not do a thorough review.

Thanks!