From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages Date: Fri, 03 May 2013 14:00:49 +0800 Message-ID: <51835291.20400@linux.vnet.ibm.com> References: <1367032402-13729-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <1367032402-13729-5-git-send-email-xiaoguangrong@linux.vnet.ibm.com> <20130503112729.942a04b2ba2566b35328f49e@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, gleb@redhat.com, avi.kivity@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: In-Reply-To: <20130503112729.942a04b2ba2566b35328f49e@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/03/2013 10:27 AM, Takuya Yoshikawa wrote: > On Sat, 27 Apr 2013 11:13:20 +0800 > Xiao Guangrong wrote: > >> +/* >> + * Fast invalid all shadow pages belong to @slot. >> + * >> + * @slot != NULL means the invalidation is caused the memslot specified >> + * by @slot is being deleted, in this case, we should ensure that rmap >> + * and lpage-info of the @slot can not be used after calling the function. >> + * >> + * @slot == NULL means the invalidation due to other reasons, we need > > The comment should explain what the "other reasons" are. > But this API may better be split into two separate functions; it depends > on the "other reasons". NO. > >> + * not care rmap and lpage-info since they are still valid after calling >> + * the function. >> + */ >> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm, >> + struct kvm_memory_slot *slot) > > You yourself is explaining this as "invalidation" in the comment. > kvm_mmu_invalidate_shadow_pages_memslot() or something... Umm, invalidate is a better name. Will update after collecting Marcelo, Gleb and other guy's comments.