summaryrefslogtreecommitdiffstats
path: root/fs/bfs
diff options
context:
space:
mode:
authorBharat Bhushan <r65777@freescale.com>2013-08-07 15:33:46 +0530
committerPaolo Bonzini <pbonzini@redhat.com>2013-10-10 11:40:08 +0200
commit40fde70d0df993d1a652d6cc69f8b4e967656170 (patch)
tree9d9ec53946c35f6335c87a6ec6ba504ed7690fbc /fs/bfs
parentcfc860253abd73e1681696c08ea268d33285a2c4 (diff)
downloadlinux-40fde70d0df993d1a652d6cc69f8b4e967656170.tar.bz2
kvm: ppc: booke: check range page invalidation progress on page setup
When the MM code is invalidating a range of pages, it calls the KVM kvm_mmu_notifier_invalidate_range_start() notifier function, which calls kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages. However, the Linux PTEs for the range being flushed are still valid at that point. We are not supposed to establish any new references to pages in the range until the ...range_end() notifier gets called. The PPC-specific KVM code doesn't get any explicit notification of that; instead, we are supposed to use mmu_notifier_retry() to test whether we are or have been inside a range flush notifier pair while we have been referencing a page. This patch calls the mmu_notifier_retry() while mapping the guest page to ensure we are not referencing a page when in range invalidation. This call is inside a region locked with kvm->mmu_lock, which is the same lock that is called by the KVM MMU notifier functions, thus ensuring that no new notification can proceed while we are in the locked region. Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com> Acked-by: Alexander Graf <agraf@suse.de> [Backported to 3.12 - Paolo] Reviewed-by: Bharat Bhushan <bharat.bhushan@freescale.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'fs/bfs')
0 files changed, 0 insertions, 0 deletions