Am 04.05.2012 13:59, schrieb Juan Quintela: > Andreas Färber <afaer...@suse.de> 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 coupled >> to CPU_SAVE_VERSION AFAICS. >> >> What really changes is that vmstate_cpu_common is now registered whether >> 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. > > 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 support > migration, it was always sent. Code now is trivial to understand: > > #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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
