From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v9 15/15] tools/libxc: Migration v2 compatibility for unmodified libxl Date: Wed, 15 Apr 2015 13:14:45 +0100 Message-ID: <552E5635.8020205@citrix.com> References: <1428686167-8279-1-git-send-email-andrew.cooper3@citrix.com> <1428686167-8279-16-git-send-email-andrew.cooper3@citrix.com> <1429098671.15516.231.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1429098671.15516.231.camel@citrix.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: Ian Campbell Cc: Wei Liu , Ian Jackson , Xen-devel List-Id: xen-devel@lists.xenproject.org On 15/04/15 12:51, Ian Campbell wrote: > On Fri, 2015-04-10 at 18:16 +0100, Andrew Cooper wrote: >> These changes cause migration v2 to behave similarly enough to legacy >> migration to function for HVM guests under an unmodified xl/libxl. >> >> The migration v2 work for libxl will fix the layering issues with the >> toolstack and qemu records, at which point this patch will be unneeded. >> >> It is however included here for people wishing to experiment with migration v2 >> ahead of the libxl work. > I think it's ultimately up to Wei as RM but I'd be in favour of actually > enabling this now, i.e. behaving as if XG_MIGRATION_V2 were set by > default and removing all the old stuff. > > Any idea if this is a sufficient compat layer for the existing remus > functionality? If this were to be enabled by default, remus would break. (Also, I wanted to offer a way for it to be very easily tested without flipping the big switch right now, in case there was something I missed) There was a remus/migration v2 series posted ages, but no followup to first round review because I believe the guys were busy trying to get remus/libxl in at the same time. > >> +#ifdef XG_LIBXL_HVM_COMPAT >> +static int dump_qemu(struct xc_sr_context *ctx) > dump_ made me thing this was going the other way (i.e. saving it), could > you s/dump/handle/ please? I think that matches the prevailing naming > scheme better Ok. The dump_ name was inherited from the legacy code, then hidden in an #if 0 for a large part of development. ~Andrew > > Apart from that last one: > Acked-by: Ian Campbell > > Ian. >