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

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

Wei, 
    Yes, basically it works for me. However I didn't test it too much. 
For example, I haven't tested the PoD functionality with the patch. 

Thanks!
Dongxiao

Wei Huang wrote:
> Dongxiao,
> 
> Thanks for re-basing the code. Does the new code work for you? I need
> to test the new code again on my machine and make sure it doesn't
> break. After that, we can ask Keir to push into upstream.
> 
> -Wei
> 
> 
> Xu, Dongxiao wrote:
>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel