kvm guest memory management (was: Re: [RFC][PATCH]Memory mapped TPR shadow featureenabling)

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Dong, Eddie wrote:
> Taking this chance to brainstorming what is the direction of slot
> structure and
> VT-d support. In later case, we have to generate a P2M (gpa to hpa or
> mpa) table
> eventually. This table won't replace slot data structure since we still
> need 
> struct page * some place, but it will help gpa_to_hpa search. Do u have
> any 
> solid idea right now? My suggestion is to add additional P2M table and
> restructure
> shadow code to use P2M table for most frequent APIs which will help
> performance.
>
> Increasing slot number will simply reduce performance of slot table :-(
>   

First, I doubt that memory slot count will really affect performance. 
The memory slot structure is small and it is likely that all slots will
be kept in cache at all times.  Walking all slots should take a lot less
time than a vmexit, even if there are 16 slots.  Placing the most
heavily used slots first reduces that time further.

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().

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?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
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/