From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Keir Fraser <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
Frediano Ziglio <frediano.ziglio@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
Jan Beulich <JBeulich@suse.com>
Subject: [PATCH 0/6] [VERY RFC] Migration Stream v2
Date: Wed, 9 Apr 2014 19:28:18 +0100 [thread overview]
Message-ID: <1397068104-23714-1-git-send-email-andrew.cooper3@citrix.com> (raw)
Hello,
Presented here for early review is a basic implementation of PV guest
migration using the v2 stream format.
PV non-live migration is believed-working; i.e. xl save/restore.
One caveat is 32bit PV domains and 64 bit toolstacks, which is expected not to
work currently. There is an architectural problem when using the toolstack
domains m2p to shoot Xen mappings from a PV guest, which is hidden by another
over-aggressive bug in the live part of v1 migration, which is why v1 currently
works (albeit with a risk of shooting too many guest PTEs). As 'live' is not
yet implemented in v2, the second bug has not been replicated.
The code has been a clean rewrite, using the v1 code as a reference but
avoiding obsolete areas (e.g. how to modify the pagetables of a 32 non-pae
guest on 32bit pae Xen).
Some design decisions have been take very deliberately (e.g. splitting the
logic for PV and hvm migration) while others have been more along the lines of
"I think its a sensible thing to do given a lack of any evidence/opinion to
the contrary".
The error handling is known to only semi-consistent. Functions return 0 for
success and non-zero for failure. This is typically -1, although errno is not
always relevant. However, the logging messages should all be relevant and
correct. Making this properly consistent will involve wider effort across all
of libxc.
Patches:
* 1 is a gross hack to allow the two versions to coexist
* 2 is mainly a header file following the specification (draft E)
* 3 is a set of python scripts for validation of streams
* 4 is some common PV code
* 5 is an implementation of PV save
* 6 is an implementation of PV restore
The rough order of forthcoming work is:
* Fix architectural bug (new hypercall required)
* Get live migration working without the risk of corrupting 32bit guests
* Get HVM migration working (conceptually easier)
* Get some of the optional features working (tmem blobs, etc)
An area needing discussing is how to do v1 -> v2 transformations for a one-time
upgrade. There is a (very basic currently) python script which can pick a v1
stream, and a separate python library to write v2 streams.
One option would be to combine these two into a program which takes two fds,
which libxc can exec() out to. There is deliberate flexibility in the v2
restore code which allows a v1 -> v2 transformation on a stream without seeking.
Anyway - the code is presented for initial comment/query/critisixm.
~Andrew
next reply other threads:[~2014-04-09 18:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 18:28 Andrew Cooper [this message]
2014-04-09 18:28 ` [PATCH 1/6] [HACK] tools/libxc: save/restore v2 framework Andrew Cooper
2014-04-09 18:28 ` [PATCH 2/6] tools/libxc: Stream specification and some common code Andrew Cooper
2014-04-09 18:28 ` [PATCH 3/6] tools/libxc: Scripts for inspection/valdiation of legacy and new streams Andrew Cooper
2014-04-09 18:28 ` [PATCH 4/6] tools/libxc: x86 pv common code Andrew Cooper
2014-04-09 18:28 ` [PATCH 5/6] tools/libxc: x86 pv save implementation Andrew Cooper
2014-04-09 18:28 ` [PATCH 6/6] tools/libxc: x86 pv restore implementation Andrew Cooper
2014-04-10 10:42 ` [PATCH 0/6] [VERY RFC] Migration Stream v2 Ian Campbell
2014-04-10 11:21 ` Andrew Cooper
2014-04-10 13:05 ` Frediano Ziglio
2014-04-10 13:49 ` Andrew Cooper
2014-04-14 17:49 ` George Dunlap
2014-04-14 18:06 ` Andrew Cooper
2014-04-14 18:16 ` George Dunlap
2014-04-14 23:43 ` Andrew Cooper
2014-04-14 18:11 ` David Vrabel
2014-04-15 8:30 ` Frediano Ziglio
2014-04-15 10:35 ` Ian Jackson
2014-04-15 10:38 ` George Dunlap
2014-04-23 13:47 ` Ian Campbell
2014-04-23 14:02 ` Andrew Cooper
2014-04-23 14:13 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1397068104-23714-1-git-send-email-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=david.vrabel@citrix.com \
--cc=frediano.ziglio@citrix.com \
--cc=keir@xen.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).