On Thu, 31 Jan 2008, Andrea Arcangeli wrote: > > - void (*invalidate_range)(struct mmu_notifier *mn, > > + void (*invalidate_range_begin)(struct mmu_notifier *mn, > > struct mm_struct *mm, > > - unsigned long start, unsigned long end, > > int lock); > > + > > + void (*invalidate_range_end)(struct mmu_notifier *mn, > > + struct mm_struct *mm, > > + unsigned long start, unsigned long end); > > }; > > start/finish/begin/end/before/after? ;)
Well lets pick one and then stick to it. > I'd drop the 'int lock', you should skip the before/after if > i_mmap_lock isn't null and offload it to the caller before taking the > lock. At least for the "after" call that looks a few liner change, > didn't figure out the "before" yet. How we offload that? Before the scan of the rmaps we do not have the mmstruct. So we'd need another notifier_rmap_callback. > Given the amount of changes that are going on in design terms to cover > both XPMEM and GRE, can we split the minimal invalidate_page that > provides an obviously safe and feature complete mmu notifier code for > KVM, and merge that first patch that will cover KVM 100%, it will The obvious solution does not scale. You will have a callback for every page and there may be a million of those if you have a 4GB process. > made so that are extendible in backwards compatible way. I think > invalidate_page inside ptep_clear_flush is the first fundamental block > of the mmu notifiers. Then once the fundamental is in and obviously > safe and feature complete for KVM, the rest can be added very easily > with incremental patches as far as I can tell. That would be my > preferred route ;) We need to have a coherent notifier solution that works for multiple scenarios. I think a working invalidate_range would also be required for KVM. KVM and GRUB are very similar so they should be able to use the same mechanisms and we need to properly document how that mechanism is safe. Either both take a page refcount or none. ------------------------------------------------------------------------- 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
