From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aY8NK-0006T1-VS for qemu-devel@nongnu.org; Tue, 23 Feb 2016 03:31:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aY8NH-0003mh-Nr for qemu-devel@nongnu.org; Tue, 23 Feb 2016 03:31:18 -0500 From: Juan Quintela In-Reply-To: <20160219085944.281f4a73@bahia.huguette.org> (Greg Kurz's message of "Fri, 19 Feb 2016 08:59:44 +0100") References: <20160218113211.9760.85475.stgit@bahia.huguette.org> <20160219001147.GN15224@voom.fritz.box> <20160219085944.281f4a73@bahia.huguette.org> Date: Tue, 23 Feb 2016 09:31:10 +0100 Message-ID: <87ziurakvl.fsf@emacs.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Laurent Vivier , qemu-devel@nongnu.org, "Dr. David Alan Gilbert" , qemu-ppc@nongnu.org, Amit Shah , David Gibson Greg Kurz wrote: > On Fri, 19 Feb 2016 11:11:47 +1100 > David Gibson wrote: > >> On Thu, Feb 18, 2016 at 12:32:11PM +0100, Greg Kurz wrote: >> > QEMU 2.4 broke the migration of old pseries machine with the addition >> > of configuration sections, which are sent unconditionally. >> > >> > We assume that QEMU 2.3 is more deployed than any newer release (based on >> > the versions currently shipped by most distros). This v3 series hence >> > reverses the logic from v2: it now fully fixes migration of old pseries >> > from/to QEMU 2.3 and provides a manual workaround for the QEMU 2.4/2.4.1/2.5 >> > case. >> > >> > With this series, I could migrate the same pseries-2.3 instance in a full >> > 2.3->2.6->2.5->2.6->2.4->2.6->2.3 cycle. >> >> Sorry, I've lost track slightly here. Does this series apply on top >> of, or instead of your earlier series that peeks for the config >> section? >> > > This v3 series applies instead of the v2 that peeks for the config section. > > It was suggested by Laurent during review, and motivated by your decision > to favor fixing 2.3 over 2.4. > > As shown in Laurent's detailed test report, migration from/to 2.3.x now works > out of the box and 2.4.x/2.5 requires qom-set. > > I was also feeling a bit uncomfortable with all these machine properties to > disable the configuration section, which was explicitly coded to be non-optional > according to the changelog of commit 61964c23. The logic inversion in v3 seem > to be friendlier with the configuration section design. > > Juan, could you share your thoughts ? As said previously, we don't have any better fix. We could try to make the "enforce" thing only for some machine types, but I guess that it would make the mess even bigger :-( And on an unrelated topic, I guess we need to "agree" in a way to add new features to migration for all machine types. Right now we have: - two x86 boards - now s390 - and now ppc - and I guess arm is on the way So, I guess we would need something like of what we have on hw/i386/pc_piix.c static void pc_compat_2_3(MachineState *machine) { PCMachineState *pcms = PC_MACHINE(machine); savevm_skip_section_footers(); if (kvm_enabled()) { pcms->smm = ON_OFF_AUTO_OFF; } global_state_set_optional(); savevm_skip_configuration(); } Really, we need something like this static void migration_compat_2_3(MachineState *machine) { savevm_skip_section_footers(); global_state_set_optional(); savevm_skip_configuration(); } to be included in every machine that cares about migration. Is there ane easy way/place where to do this globaly? Later, Juan.