Re: [PATCH 1/2] KVM: mmu_notifier: Flush TLBs before releasing mmu_lock

[Andrea Arcangeli <aarcange@redhat.com>]

On Fri, Feb 10, 2012 at 03:52:49PM +0800, Xiao Guangrong wrote:
> On 02/10/2012 02:28 PM, Takuya Yoshikawa wrote:
> 
> > Other threads may process the same page in that small window and skip
> > TLB flush and then return before these functions do flush.
> > 
> 
> 
> It is possible that flush tlb in mmu lock only when writeable
> spte is invalided? Sometimes, kvm_flush_remote_tlbs need
> long time to wait.

readonly isn't enough to defer the flush after mmu_lock is
released... if you do it only for writable spte, then what can happen
is the guest may read random data and would crash.

However for this case, the mmu_notifier methods (and only them) are
perfectly safe to flush the shadow MMU TLB after the mmu_lock is
released because the page reference is guaranteed hold by the caller
(not the case for any other place where a spte gets dropped in KVM,
all other places dropping sptes, can only on the mmu notifier to block
on the mmu_lock in order to have a guarantee of the page not being
freed under them, so in every other place the shadow MMU TLB flush
must happen before releasing the mmu_lock so the mmu_notifier will
wait and prevent the page to be freed until all other CPUs running in
guest mode stopped accessing it).