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/ _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
