From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roedel, Joerg" Subject: Re: large page support for kvm Date: Fri, 15 Feb 2008 08:40:07 +0100 Message-ID: <20080215074007.GC12008@amd.com> References: <479F604C.20107@qumranet.com> <20080130184035.GS6960@amd.com> <47A16054.6080201@qumranet.com> <20080211154901.GA11936@dmt> <47B1894A.1030208@qumranet.com> <20080213001519.GA32134@dmt> <47B2921F.1040905@qumranet.com> <20080214231739.GA7787@dmt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Avi Kivity To: "Marcelo Tosatti" Return-path: In-Reply-To: <20080214231739.GA7787@dmt> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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/