From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 00/27] Libxl migration v2 Date: Wed, 17 Jun 2015 10:45:43 +0100 Message-ID: <558141C7.1020800@citrix.com> References: <1434375880-30914-1-git-send-email-andrew.cooper3@citrix.com> <5580D379.9080901@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5580D379.9080901@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 17/06/15 02:55, Wen Congyang wrote: > On 06/15/2015 09:44 PM, Andrew Cooper wrote: >> This series adds support for the libxl migration v2 stream, and untangles the >> existing layering violations of the toolstack and qemu records. >> >> At the end of the series, legacy migration is no longer used. >> >> Note: Remus support is broken and (RFC) fixed in separate patches in this >> series. It was too tangled to fix in a bisectable fashon. Plain >> suspend/migrate/resume however is (should be) bisectable along the entire >> series. >> >> There are a couple of outstanding questions: >> >> 1) What to do about the toolstack/xenstore record. It is currently by being >> passed around as a blob, but it might be better to split it out. >> >> 2) What (if any) ABI/API qualifications are needed? (Particularly in reference >> to patch 21) >> >> The Remus code is untested by me, but is hopefully in the correct ballpark. >> All other combinations of suspend/migrate/resume have been tested with PV and >> HVM guests (qemu-trad and qemu-upstream), including 32 -> 64 bit migration >> (which was the underlying bug causing us to write migration v2 in the first >> place). >> >> There are some further improvements which could be made. In particular, it >> appears that sending the toolstack record on each checkpoint is redundant, and >> there is certainly room for some more pruning of the legacy migration code. > Do you mean: libxl__toolstack_save is harmless, and it can be called when the > guest is running? > > Thanks > Wen Congyang It is harmless when a guest is running. It contains the contents of the device models "/physmap" xenstore tree, which is empty for a PV or qemu-trad HVM guest and constant-after-setup for qemu-upstream HVM guests (I don't see why this information isn't maintained in the Qemu record itself because nothing else uses it). ~Andrew