From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: Error restoring DomU when using GPLPV Date: Tue, 15 Sep 2009 15:27:59 -0700 Message-ID: <4AB014EF.1050601@oracle.com> References: Reply-To: mukesh.rathor@oracle.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Joshua West , Dan Magenheimer , xen-devel , "Kurt C. Hackel" , "annie.li@oracle.com" , James Harper , "wayne.gong@oracle.com" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 15/09/2009 22:25, "Keir Fraser" wrote: > >> No, it doesn't. I agree that after the first migration tot_pages will have >> increased to 0x83ed. But I do not agree that it will continue to increase by >> three pages on each future migration. Look at it this way -- three GPFNs >> (guest-physical pages) have changed from xenheap pages to domheap pages >> across that first migration. On future migrations they will be migrated just >> like any other ordinary domheap page, since that's what they now are. And >> tot_pages will therefore not change. Right? > > Actually of course you do the right thing with the shinfo page, so actually > one page per migration does get switched back to being a Xenheap page (the > shinfo page) and tot_pages actually increases by 3 on the first migration, > then decreases by 1 when shinfo gets remapped by the PV drivers. Then > increases by 1 on every future migration (which is the shinfo Xenheap page > getting changed into a domheap page), and then decreases by 1 when shinfo > gets remapped by the PV drivers. > > But even setting things out exactly right as above, the end result is the > same: I *still* cannot explain Annie's result. The bug in her driver is that its only remapping shinfo page, and NOT the 2 shared grant frames. tot_pages hence increases by 2 every migration. I can see all in kdb. tot_pages goes up by 3, then down by 1 as shared info frame is remapped, and remains there. Next migration, it goes up by 3, down by 1 again. So each migration leaks 2 frames. The initial difference is 21 frames between tot and max, hence after 10 migrations it fails. (BTW, no max_mem specified in config file, I'm told it means no POD). On linux side, driver remaps shinfo page + both grant frames. So, it goes up by 3 for a moment, then comes remap and down by 3, back to where it was. If tot_pages == max_pages, then mig will fail. Which brings me to a question, to test out balloon changes, what would be the best way to get tot_pages equal to max_pages. xm mem-set doesn't quite get me there. Occassionally I see the two same after starting guest, but I've not figured out what causes that to happen. thakns Mukesh > -- Keir > >> This is why I still cannot understand or explain Annie's experimental >> result. >