From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm guest memory management Date: Sun, 30 Sep 2007 10:55:26 +0200 Message-ID: <46FF647E.6080506@qumranet.com> References: <46F8C84F.7090605@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A022AE787@pdsmsx411.ccr.corp.intel.com> <46FD1288.9030507@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A022AEA2F@pdsmsx411.ccr.corp.intel.com> <46FD323C.3090905@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A022AEAFE@pdsmsx411.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A022AEAFE-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/