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

[Wei Huang <wei.huang2@xxxxxxx>]

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