This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] HVM save/restore issue

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] HVM save/restore issue
From: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Date: Tue, 20 Mar 2007 20:25:25 +0800
Cc: Tim <Tim.Deegan@xxxxxxxxxxxxx>, Ewan Mellor <ewan@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Delivery-date: Tue, 20 Mar 2007 05:30:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C225618C.BD90%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070320084652.GK21485@xxxxxxxxxxxxxxxxxxxxxx> <C225618C.BD90%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11
On Tue, Mar 20, 2007 at 10:01:48AM +0000, Keir Fraser wrote:
> On 20/3/07 08:46, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:
> >> 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?
> Other thoughts on xc_hvm_restore as it is right now, and its use/abuse of
> 'store_mfn' parameter to pass in memory_static_min. I think this can be
> reasonably got rid of:
>  1. Do the setmaxmem hypercall in Python. There's no reason to be doing it
> in xc_hvm_save().

1.xc_linux_save also has setmaxmem
2.even do it in Python, we still need the memsize for setmaxmem

>  2. Instead of preallocating the HVM memory, populate the physmap on demand
> as we do now in xc_linux_restore. I'd do this by having an 'allocated
> bitmap', indexed by guest pfn, where a '1' means that page is already
> populated. Alternatively we might choose to avoid needing the bitmap by
> always doing populate_physmap() whenever we see a pfn, and have Xen
> guarantee that to be a no-op if RAM is already allocated at that pfn.

current hvm restore just try to create the mem layout (same as when 
create)firstly then shape it gradually, so need memsize when creating guest.

seems you want another method: save the mem layout in xc_hvm_save and populate 
the same one when restore, right?
it's okay for me. BTW, i prefer bitmap way if we can make it efficient.

> If we go the bitmap route I'd just make it big enough for a 4GB guest up
> front (only 128kB required) and then realloc() it to be twice as big
> whenever we go off the end of the current bitmap.
>  -- Keir

best rgds,

Xen-devel mailing list