On Thu, Jan 24, 2008 at 07:56:43AM +0200, Avi Kivity wrote: > What I need is a list of (mm, va) that map the page. kvm doesn't have > access to that, export notifiers do. It seems reasonable that export > notifier do that rmap walk since they are part of core mm, not kvm.
Yes. Like said in earlier email we could ignore the slowdown and duplicate the mm/rmap.c code inside kvm, but that looks a bad layering violation and it's unnecessary, dirty and suboptimal IMHO. > Alternatively, kvm can change its internal rmap structure to be page based > instead of (mm, hva) based. The problem here is to size this thing, as we > don't know in advance (when the kvm module is loaded) whether 0% or 100% > (or some value in between) of system memory will be used for kvm. Another issue is that for things like the page sharing driver, it's more convenient to be able to know exactly which "sptes" belongs to a certain userland mapping, and only that userland mapping (not all others mappings of the physical page). So if the rmap becomes page based, it'd be nice to still be able to find the "mm" associated with that certain spte pointer to skip all sptes in the other "mm" during the invalidate. ------------------------------------------------------------------------- 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