From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQHH5-0008Hu-GN for qemu-devel@nongnu.org; Fri, 04 May 2012 08:06:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQHH2-0008MG-Ds for qemu-devel@nongnu.org; Fri, 04 May 2012 08:06:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58073 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQHH2-0008Lv-4Z for qemu-devel@nongnu.org; Fri, 04 May 2012 08:06:12 -0400 Message-ID: <4FA3C632.7070600@suse.de> Date: Fri, 04 May 2012 14:06:10 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <426453fa2757fc516046dd54832f62503cc95391.1336128412.git.quintela@redhat.com> <4FA3C1A1.8010907@suse.de> <8762ccb1ii.fsf@elfo.elfo> In-Reply-To: <8762ccb1ii.fsf@elfo.elfo> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com Cc: qemu-devel@nongnu.org Am 04.05.2012 13:59, schrieb Juan Quintela: > Andreas F=C3=A4rber wrote: >> Am 04.05.2012 12:54, schrieb Juan Quintela: >>> Some cpu's definitions define CPU_SAVE_VERSION, others not, but they = have >> >> "CPUs' definitions"? >> >>> defined cpu_save/load. >> >> This commit message sounds wrong. Use of cpu_save/load is still couple= d >> to CPU_SAVE_VERSION AFAICS. >> >> What really changes is that vmstate_cpu_common is now registered wheth= er >> or not the target supports loading/saving the target-specific parts, >> isn't it? Is that really useful? Either way, the commit message should >> be updated. >=20 > For the cpus that weren't using CPU_SAVE_VERSION, we now register the > system as unmigratable, so this don't matter. For the cpus that suppor= t > migration, it was always sent. Code now is trivial to understand: >=20 > #if !defined(CONFIG_USER_ONLY) > vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env); > vmstate_register(NULL, cpu_index, &vmstate_cpu, env); > #endif No, that's not what's in the patch. > Befor it was a maze of ifdefs. No change of behaviour with what we had > before. For either cpus that had[not] support for migration or not. Please look at the patch again - it turns the one-ifdef block into two nested ifdefs. So therefore it is my understanding that - in lack of unmigratable VMSDs this patch - possibly temporarily, not all patches have arrived yet - changes the migration format in an odd way. In that case we should consider reordering the patch within the series. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg