From: Keir Fraser Subject: Re: [PATCH 1/2] PV hugepages - Xen patch Date: Wed, 08 Oct 2008 19:11:35 +0100 Message-ID: References: <200810081205.16978.dcm@mccr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <200810081205.16978.dcm@mccr.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave McCracken , xen-devel@lists.xensource.com Cc: Ian Pratt List-Id: xen-devel@lists.xenproject.org On 8/10/08 18:05, "Dave McCracken" wrote: > On Friday 03 October 2008, Keir Fraser wrote: >> Some issues: >> =A0* You need to check return value of get_page_from_pagenr() on every pag= e >> of the superpage. Any one of them can fail, causing you to undo your wor= k >> so far and then fail. >> =A0* You need to get_page_type(PGT_writable) on every page if the superpag= e >> mapping asserts _PAGE_RW. Otherwise the guest is getting write access >> without that being asserted in the reference counts. >> =A0* Look at get_page_from_l1e() for an example of how this is done for a >> single page. You need to do similar work for every page of the super-pag= e. >=20 > Ok, here's a version of the patch with all these issues addressed. >=20 >> =A0* This surely breaks save/restore, since the restore code is not >> superpage-aware. >=20 > 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 and 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? -- Keir