From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhai, Edwin" Subject: Re: HVM save/restore issue Date: Tue, 20 Mar 2007 16:46:52 +0800 Message-ID: <20070320084652.GK21485@edwin-srv.sh.intel.com> References: <20070320081236.GJ21485@edwin-srv.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline 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: Tim , Ewan Mellor , xen-devel@lists.xensource.com, "Zhai, Edwin" List-Id: xen-devel@lists.xenproject.org On Tue, Mar 20, 2007 at 08:29:30AM +0000, Keir Fraser wrote: > On 20/3/07 08:12, "Zhai, Edwin" wrote: > > > latest HVM save/restore break again:( > > > > i use the memsize(the number in the xmexample.hvm) deduced from > > 'memory_static_min' to calculate some HVM PFNs when restore. > > Out of interest: why would you do this? I glanced upon the code you are > referring to in xc_hvm_restore.c yesterday, and it struck me as particularly > gross. All three PFNs (ioreq, bufioreq, xenstore) could be saved in the > store after building the domain and then saved/restored as part of the > Python-saved data. The situation is easier than for a PV guest because PFNs save all PFNs directly is good idea. i have this code to keep create and restore process similar. i'd like directly save/restore all pfns in xc_hvm_{save,restore}. is this your want? > do not change across save/restore. > > The more assumptions about memory layout we bake into xc_hvm_{save,restore} > now, the more we have to unbake when the HVM memory map becomes more dynamic > (balloon driver support, in particular). Making these assumptions to some > extent for now is okay, but we should avoid it where possible. > > -- Keir > -- best rgds, edwin