Dong, Eddie wrote: > >> But to the bigger picture. We're quite close to using user-allocated >> memory for the guest, instead of kernel allocated memory. This means >> that userspace will allocate a memory region and assign it to kvm as a >> memory slot. On x86-64, where we have a large address space, >> this means >> that all of memory can be in just one slot (well, slots also >> allow us to >> do tracking of dirty pages on a subset of memory, so maybe three slots >> are needed). In effect, the Linux process page tables become the g2h >> (or p2m) tables, and access to guest memory is a simple >> copy_to_user()/copy_from_user(). >> > > There are couple reasons that g2h can't server this. > A VT-d device or EPT/NPT table need to translate from guest physical > to machine physical address, while g2h uses host mode va as index. > Other reason is that g2h also include host user space memory & kernel > memory which guest should never touch. (A bad programmed VT-d device > may modify the memory listed by VT-d table). > >
For EPT, we can't use the host page tables because EPT does not support the dirty bit. So EPT requires duplication of the page tables anyway. > Dirty tracking can certainly be serviced even using p2m solely. > > >> User-allocated memory will enable the following features: >> - s390 support >> - guest swapping >> - page migration (where a guest is migrated from one NUMA node >> to another) >> - in conjunction with a de-duplicating file system, page sharing >> among guests >> - inter-guest shared memory (mmap() one file in two or more guests) >> - easier use of huge pages >> - more? >> >> > > This doesn't conflict with my suggestion though the p2m table then > need to be dynamically modifed in case swapping happens. > The nice thing about using the host page tables is that it's automatically updated to reflect changes in mapping. Translating a page (gfn_to_page) becomes a call to get_user_pages(). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
