From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave McCracken Subject: Re: [PATCH 1/2] PV hugepages - Xen patch Date: Wed, 8 Oct 2008 13:28:46 -0500 Message-ID: <200810081328.46262.dcm@mccr.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Pratt , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wednesday 08 October 2008, Keir Fraser wrote: > On 8/10/08 18:05, "Dave McCracken" wrote: > > On Friday 03 October 2008, Keir Fraser wrote: > >> =A0* This surely breaks save/restore, since the restore code is not > >> superpage-aware. > > > > I don't have this one solved yet. I'm working on it. > > Actually this is an interesting one. For a PV guest it may be in general > unsolvable, since the target machine may not have allocatable 2MB extents. > It may also screw live migration since 2MB is a very coarse granularity to > do dirty-page tracking. One option: perhaps the PV kernel could shatter a= nd > then reconstruct (as best it can) superpage mappings across save/restore? > I'm actually not sure what's for the best here. Perhaps just make 2MB > mappings and save/restore mutually exclusive for now? Yeah, that's what I'm finding. I think it's a good idea to document for no= w=20 that hugepages don't work with save/restore. I'll continue to dig into it= =20 and try to figure out a scheme to make it work as a future enhancement. Dave McCracken