Re: large page support for kvm

["Roedel, Joerg" <joerg.roedel@amd.com>]

On Fri, Feb 15, 2008 at 12:17:39AM +0100, Marcelo Tosatti wrote:
> 
> On Wed, Feb 13, 2008 at 08:45:51AM +0200, Avi Kivity wrote:
> > >gfn_to_page() needs to grab the struct page corresponding to the large
> > >page, not the offset struct page for the faulting 4k address within
> > >the large frame. Since gfn_to_page can sleep, there is no way to do
> > >that in the mapping logic which happens under mmu_lock protection.
> > >We don't want to grab the large page frame "struct page" unless the
> > >is_largepage_backed() checks are successful.
> > >
> > >The checks could be done in page_fault() if walker->level == 2, before
> > >gfn_to_page()... But I don't see much difference of that and doing 
> > >it inside walk_addr(). What do you say?
> > >
> > >  
> > 
> > I'd like to keep walk_addr() independent of the rest of the mmu (i.e. 
> > walk_addr is 100% guest oriented). Also, the issue you point out is 
> > shared by direct_map which doesn't call walk_addr().
> > 
> > An unrelated issue (pointed out by Jun Nakajima) is that this kills 
> > dirty log tracking (needed for migration). It could be solved simply by 
> > not using large page backing if dirty log tracking is enabled for that slot.
> 
> Ok, fixed your comments and a bug which a root page was shadowed in the
> large area being mapped. access.flat is happy.
> 
> Joerg, can you give this a try on a NPT-enabled system (need the
> attached qemu-largepage-hack.patch).

Yeah. I will give it a try today. I am very curious about the
performance numbers.

Joerg

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy



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