From mboxrd@z Thu Jan  1 00:00:00 1970
From: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Subject: Re: [PATCH 09/12] KVM: MMU: coalesce zapping page after
 mmu_sync_children
Date: Thu, 25 Feb 2016 17:10:46 +0800
Message-ID: <56CEC516.7010306@linux.intel.com>
References: <1456319873-34182-1-git-send-email-pbonzini@redhat.com>
 <1456319873-34182-10-git-send-email-pbonzini@redhat.com>
 <56CE63D1.40009@lab.ntt.co.jp> <56CEAEA7.8080702@linux.intel.com>
 <56CEC003.1070402@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mtosatti@redhat.com
To: Paolo Bonzini <pbonzini@redhat.com>,
	Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Return-path: <kvm-owner@vger.kernel.org>
Received: from mga04.intel.com ([192.55.52.120]:29836 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1759483AbcBYJKv (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 25 Feb 2016 04:10:51 -0500
In-Reply-To: <56CEC003.1070402@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>



On 02/25/2016 04:49 PM, Paolo Bonzini wrote:
>
>
> On 25/02/2016 08:35, Xiao Guangrong wrote:
>>> This may release the mmu_lock before committing the zapping.
>>> Is it safe?  If so, we may want to see the reason in the changelog.
>>
>> It is unsafe indeed, please do not do it.
>
> Can you explain why?  kvm_zap_obsolete_pages does the same.

It's not the same, please see the comment in  kvm_mmu_invalidate_zap_all_pages:
	/*
	 * Notify all vcpus to reload its shadow page table
	 * and flush TLB. Then all vcpus will switch to new
	 * shadow page table with the new mmu_valid_gen.
	 *
	 * Note: we should do this under the protection of
	 * mmu-lock, otherwise, vcpu would purge shadow page
	 * but miss tlb flush.
	 */
	kvm_reload_remote_mmus(kvm);

That means the tlb is flushed before releasing mmu-lock.

A example is in rmap_write_protect(), when KVM creates a shadow page table for
the the guest, it detects no spte pointing to the gfn, so tlb is not flushed so
that guest can freely updates its pte.