Re: [RFC PATCH v2 5/5] KVM: Unmap pages only when it's indeed protected for NUMA migration

From: Sean Christopherson <seanjc@google.com>
To: bibo mao <maobibo@loongson.cn>
Cc: Yan Zhao <yan.y.zhao@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, pbonzini@redhat.com,
	mike.kravetz@oracle.com, apopple@nvidia.com, jgg@nvidia.com,
	rppt@kernel.org, akpm@linux-foundation.org, kevin.tian@intel.com,
	david@redhat.com
Subject: Re: [RFC PATCH v2 5/5] KVM: Unmap pages only when it's indeed protected for NUMA migration
Date: Wed, 16 Aug 2023 06:39:20 -0700	[thread overview]
Message-ID: <ZNzRiL9e2wzmB7KI@google.com> (raw)
In-Reply-To: <624efb22-8723-d813-0943-edab2870b51d@loongson.cn>

On Wed, Aug 16, 2023, bibo mao wrote:
> 
> 
> 在 2023/8/16 15:18, Yan Zhao 写道:
> > On Wed, Aug 16, 2023 at 03:29:22PM +0800, bibo mao wrote:
> >>> Flush must be done before kvm->mmu_lock is unlocked, otherwise,
> >>> confusion will be caused when multiple threads trying to update the
> >>> secondary MMU.
> >> Since tlb flush is delayed after all pte entries are cleared, and currently
> >> there is no tlb flush range supported for secondary mmu. I do know why there
> >> is confusion before or after kvm->mmu_lock.
> > 
> > Oh, do you mean only do kvm_unmap_gfn_range() in .invalidate_range_end()?
> yes, it is just sketchy thought for numa balance scenery, 
> do kvm_unmap_gfn_range() in invalidate_range_end rather than
> invalidate_range_start.

That is not an option, it's a direction violation of the mmu_notifier contract.
Secondary MMUs must drop all references before returning from invalidate_range_start().