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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
