WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support

To: "Huang2, Wei" <Wei.Huang2@xxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
From: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Date: Wed, 13 Jan 2010 12:07:33 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Tue, 12 Jan 2010 20:09:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <034622152516C547BE5EA19D5EFC86287E106B@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <034622152516C547BE5EA19D5EFC86287E0ED0@xxxxxxxxxxxxxxxxx> <de76405a0903181020i7e44a9d4o762e9045d085a97b@xxxxxxxxxxxxxx> <034622152516C547BE5EA19D5EFC86287E106B@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acmn7d4B/O9zqd3vQ/iZlCIvaXJacgAeskTAOucWNjA=
Thread-topic: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
Hi, Wei, 
        I digged out this thread from looooong history...
        Do you still have plan to push your 1gb_p2m and 1gb_tool patches into 
upstream? 
        I rebased them to fit the latest upstream code (the 1gb_tools.patch is 
not changed). 
        Comment on that or any new idea? Thanks!

Best Regards,
-- Dongxiao

Huang2, Wei wrote:
> Here are patches using the middle approach. It handles 1GB pages in
> PoD by remapping 1GB with 2MB pages & retry. I also added code for 1GB
> detection. Please comment.
> 
> Thanks a lot,
> 
> -Wei
> 
> -----Original Message-----
> From: dunlapg@xxxxxxxxx [mailto:dunlapg@xxxxxxxxx] On Behalf Of George
> Dunlap
> Sent: Wednesday, March 18, 2009 12:20 PM
> To: Huang2, Wei
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; keir.fraser@xxxxxxxxxxxxx; Tim
> Deegan Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table
> Support 
> 
> Thanks for doing this work, Wei -- especially all the extra effort for
> the PoD integration.
> 
> One question: How well would you say you've tested the PoD
> functionality?  Or to put it the other way, how much do I need to
> prioritize testing this before the 3.4 release?
> 
> It wouldn't be a bad idea to do as you suggested, and break things
> into 2 meg pages for the PoD case.  In order to take the best
> advantage of this in a PoD scenario, you'd need to have a balloon
> driver that could allocate 1G of continuous *guest* p2m space, which
> seems a bit optimistic at this point...
> 
>  -George
> 
> 2009/3/18 Huang2, Wei <Wei.Huang2@xxxxxxx>:
>> Current Xen supports 2MB super pages for NPT/EPT. The attached
>> patches extend this feature to support 1GB pages. The PoD
>> (populate-on-demand) introduced by George Dunlap made P2M
>> modification harder. I tried to preserve existing PoD design by
>> introducing a 1GB PoD cache list. 
>> 
>> 
>> 
>> Note that 1GB PoD can be dropped if we don't care about 1GB when PoD
>> is enabled. In this case, we can just split 1GB PDPE into 512x2MB
>> PDE entries and grab pages from PoD super list. That can pretty much
>> make 1gb_p2m_pod.patch go away. 
>> 
>> 
>> 
>> Any comment/suggestion on design idea will be appreciated.
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> -Wei
>> 
>> 
>> 
>> 
>> 
>> The following is the description:
>> 
>> === 1gb_tools.patch ===
>> 
>> Extend existing setup_guest() function. Basically, it tries to
>> allocate 1GB pages whenever available. If this request fails, it
>> falls back to 2MB. If both fail, then 4KB pages will be used.
>> 
>> 
>> 
>> === 1gb_p2m.patch ===
>> 
>> * p2m_next_level()
>> 
>> Check PSE bit of L3 page table entry. If 1GB is found (PSE=1), we
>> split 1GB into 512 2MB pages. 
>> 
>> 
>> 
>> * p2m_set_entry()
>> 
>> Configure the PSE bit of L3 P2M table if page order == 18 (1GB).
>> 
>> 
>> 
>> * p2m_gfn_to_mfn()
>> 
>> Add support for 1GB case when doing gfn to mfn translation. When L3
>> entry is marked as POPULATE_ON_DEMAND, we call
>> 2m_pod_demand_populate(). Otherwise, we do the regular address
>> translation (gfn ==> mfn). 
>> 
>> 
>> 
>> * p2m_gfn_to_mfn_current()
>> 
>> This is similar to p2m_gfn_to_mfn(). When L3 entry s marked as
>> POPULATE_ON_DEMAND, it demands a populate using
>> p2m_pod_demand_populate(). Otherwise, it does a normal translation.
>> 1GB page is taken into consideration. 
>> 
>> 
>> 
>> * set_p2m_entry()
>> 
>> Request 1GB page
>> 
>> 
>> 
>> * audit_p2m()
>> 
>> Support 1GB while auditing p2m table.
>> 
>> 
>> 
>> * p2m_change_type_global()
>> 
>> Deal with 1GB page when changing global page type.
>> 
>> 
>> 
>> === 1gb_p2m_pod.patch ===
>> 
>> * xen/include/asm-x86/p2m.h
>> 
>> Minor change to deal with PoD. It separates super page cache list
>> into 2MB and 1GB lists. Similarly, we record last gpfn of sweeping
>> for both 2MB and 1GB. 
>> 
>> 
>> 
>> * p2m_pod_cache_add()
>> 
>> Check page order and add 1GB super page into PoD 1GB cache list.
>> 
>> 
>> 
>> * p2m_pod_cache_get()
>> 
>> Grab a page from cache list. It tries to break 1GB page into 512 2MB
>> pages if 2MB PoD list is empty. Similarly, 4KB can be requested from
>> super pages. The breaking order is 2MB then 1GB.
>> 
>> 
>> 
>> * p2m_pod_cache_target()
>> 
>> This function is used to set PoD cache size. To increase PoD target,
>> we try to allocate 1GB from xen domheap. If this fails, we try 2MB.
>> If both fail, we try 4KB which is guaranteed to work.
>> 
>> 
>> 
>> To decrease the target, we use a similar approach. We first try to
>> free 1GB pages from 1GB PoD cache list. If such request fails, we
>> try 2MB PoD cache list. If both fail, we try 4KB list.
>> 
>> 
>> 
>> * p2m_pod_zero_check_superpage_1gb()
>> 
>> This adds a new function to check for 1GB page. This function is
>> similar to p2m_pod_zero_check_superpage_2mb().
>> 
>> 
>> 
>> * p2m_pod_zero_check_superpage_1gb()
>> 
>> We add a new function to sweep 1GB page from guest memory. This is
>> the same as p2m_pod_zero_check_superpage_2mb().
>> 
>> 
>> 
>> * p2m_pod_demand_populate()
>> 
>> The trick of this function is to do remap_and_retry if
>> p2m_pod_cache_get() fails. When p2m_pod_get() fails, this function
>> will splits p2m table entry into smaller ones (e.g. 1GB ==> 2MB or
>> 2MB ==> 4KB). That can guarantee populate demands always work. 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel

Attachment: 1gb_tools.patch
Description: 1gb_tools.patch

Attachment: 1gb_p2m_rebase.patch
Description: 1gb_p2m_rebase.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>