Re: large page support for kvm

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

Joerg Roedel wrote:
> On Tue, Jan 29, 2008 at 07:20:12PM +0200, Avi Kivity wrote:
>
>   
>> 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.
>>     
>
> You need to take care the the 2MB gpa is aligned 2 MB host physical to
> be able to map it correctly with a large pte. So maybe we need two
> memslots for 1MB-1GB. One for 1MB-2MB using normal 4kb pages and one
> from 2MB-1GB which can be allocated using HugeTLBfs.
>
>   

Another option is to allocate all memory starting from address zero 
using hugetlbfs, and pass 0-640K as one memslot and 1MB+ as another. In 
case the kernel needs to support both methods (e.g. it must handle a 
memslot that starts in the middle of a large page).

>> - 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.
>>     
>
> This sounds straight forward to me. All you need is a short value for
> every potential large page and initialize it with -1 if the host page is
> a large page and with 0 otherwise. Every time this value reaches -1 we
> can map the page with a large pte (and the guest maps with large pte).
>
>   

You don't know whether the host page is a large page in advance. It 
needs to be checked during pagefault time.

>> - 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.
>>     
>
> Yes, I think that too. But with shadow paging it really depends on the
> guest if the performance increasement is long-term. In a Linux guest,
> for example, the direct mapped memory will become fragmented over
> time (together with the location of the page tables). So the
> number of potential large page mappings will likely decrease over
> time.
>
>   

Yes, that's why it is important to be able to fail fast when checking 
whether we can use a large spte.


-- 
Any sufficiently difficult bug is indistinguishable from a feature.


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