On Sat, 16 Feb 2008 11:48:27 +0100 Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> +void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn, > + struct mm_struct *mm, > + unsigned long start, unsigned long > end, > + int lock) > +{ > + for (; start < end; start += PAGE_SIZE) > + kvm_mmu_notifier_invalidate_page(mn, mm, start); > +} > + > +static const struct mmu_notifier_ops kvm_mmu_notifier_ops = { > + .invalidate_page = kvm_mmu_notifier_invalidate_page, > + .age_page = kvm_mmu_notifier_age_page, > + .invalidate_range_end = kvm_mmu_notifier_invalidate_range_end, > +}; So this doesn't implement ->invalidate_range_start(). By what means does it prevent new mappings from being established in the range after core mm has tried to call ->invalidate_rande_start()? mmap_sem, I assume? > + /* set userspace_addr atomically for kvm_hva_to_rmapp */ > + spin_lock(&kvm->mmu_lock); > + memslot->userspace_addr = userspace_addr; > + spin_unlock(&kvm->mmu_lock); are you sure? kvm_unmap_hva() and kvm_age_hva() read ->userspace_addr a single time and it doesn't immediately look like there's a need to take the lock here? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel