The npt patches started me thinking on large page support (2MB/4MB pages), and I think we can implement them even when npt/ept are not available.
Here's a rough sketch of my proposal: - For every memory slot, allocate an array containing one int for every potential large page included within that memory slot. Each entry in the array contains the number of write-protected 4KB pages within the large page frame corresponding to that entry. For example, if we have a memory slot for gpas 1MB-1GB, we'd have an array of size 511, corresponding to the 511 2MB pages from 2MB upwards. If we shadow a pagetable at address 4MB+8KB, we'd increment the entry corresponding to the large page at 4MB. When we unshadow that page, decrement the entry. - If we attempt to shadow a large page (either a guest pse pte, or a real-mode pseudo pte), we check if the host page is a large page. If so, we also check the write-protect count array. If the result is zero, we create a shadow pse pte. - Whenever we write-protect a page, also zap any large-page mappings for that page. This means rmap will need some extension to handle pde rmaps in addition to pte rmaps. - qemu is extended to have a command-line option to use large pages to back guest memory. Large pages should improve performance significantly, both with traditional shadow and npt/ept. Hopefully we will have transparent Linux support for them one day. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
