On Sun, 2008-03-23 at 12:15 +0200, Avi Kivity wrote: > >> Can you convert the page tables at a later time without doing a > >> wholesale replacement of the mm? It should be a bit easier to keep > >> people off the pagetables than keep their grubby mitts off the mm > >> itself. > >> > > > > Yes, as far as I can see you're right. And whatever we do in arch code, > > after all it's just a work around to avoid a new clone flag. > > If something like clone() with CLONE_KVM would be useful for more > > architectures than just s390 then maybe we should try to get a flag. > > > > Oh... there are just two unused clone flag bits left. Looks like the > > namespace changes ate up a lot of them lately. > > > > Well, we could still play dirty tricks like setting a bit in current > > via whatever mechanism which indicates child-wants-extended-page-tables > > and then just fork and be happy. > > > > How about taking mmap_sem for write and converting all page tables > in-place? I'd rather avoid the need to fork() when creating a VM.
That was my initial approach as well. If all the page table allocations can be fullfilled the code is not too complicated. To handle allocation failures gets tricky. At this point I realized that dup_mmap already does what we want to do. It walks all the page tables, allocates new page tables and copies the ptes. In principle I would reinvent the wheel if we can not use dup_mmap. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. ------------------------------------------------------------------------- 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
