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: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Subject: Re: [Xen-devel] HVM save/restore issue
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Tue, 20 Mar 2007 10:01:48 +0000
Cc: Tim <Tim.Deegan@xxxxxxxxxxxxx>, Ewan Mellor <ewan@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Mar 2007 03:01:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070320084652.GK21485@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acdq1sX0BL0VotbKEduzOgAX8io7RQ==
Thread-topic: [Xen-devel] HVM save/restore issue
User-agent: Microsoft-Entourage/
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().
 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.

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

Xen-devel mailing list