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] save/restore image format

To: "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>
Subject: Re: [Xen-devel] save/restore image format
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Tue, 26 Sep 2006 12:37:20 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 26 Sep 2006 04:38:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45189BE5.1050005@xxxxxxxxx>
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: <45189BE5.1050005@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Sep 26, 2006 at 11:17:57AM +0800, Zhai, Edwin wrote:

> ian/keir,
> this is a proposal for save/restore image format with more 
> information(version, host/gust info...).

The extra information in the header seems /much/ improved. I'm not sure
why cpu freq is there? This is a dynamic value!

cpu id data must be in a separate 'section' since it likely doesn't make
sense for other processor types, or at least, they'll have a different

I still believe we should use more or less the same format for core
files too; in that respect we need a header field for the /type/ of
image. This could also identify HVM images, etc.

What I'd like to see is something very ELF-like: there's a simple
header, followed by a list of sections. For saved files and core files
they would have the section offset values filled in. For migration, we'd
have a special sentinel value (or a different image type) indicating
that the contents are streamed and the offsets are unknown.

So we'd have a section for guest config, a section for cpu-id and the
like, etc. You could represent, say, the number and size of entries in
the vcpu config section just like ELF does, in the section table, thus
the section would have just the vcpu context.

Your document doesn't have the p2m frame list section, or the
"extended-info" structure that's rather unceromoniously plonked in for
extended-cr3 guests. It also misses the unwritten pages array and the
shared info page. Unless you're suggesting that we have a completely
different format for HVM guests. I hope not!

Approaching this in an ELF-like manner naturally gets us a clear image
format that's easily extensible and understandable, and it'd be great if
we could do this now.


Xen-devel mailing list