[Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION
Some cpu's definitions define CPU_SAVE_VERSION, others not, but they have
defined cpu_save/load.
Signed-off-by: Juan Quintela
---
exec.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 0607c9b..cba333f 100644
--- a/exec.c
+++ b/exec.c
@@ -650,7 +650,7 @@ void cpu_exec_init_all(void)
#endif
}
-#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
+#if !defined(CONFIG_USER_ONLY)
static int cpu_common_post_load(void *opaque, int version_id)
{
@@ -717,11 +717,13 @@ void cpu_exec_init(CPUArchState *env)
#if defined(CONFIG_USER_ONLY)
cpu_list_unlock();
#endif
-#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
+#if !defined(CONFIG_USER_ONLY)
vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env);
+#if defined(CPU_SAVE_VERSION)
register_savevm(NULL, "cpu", cpu_index, CPU_SAVE_VERSION,
cpu_save, cpu_load, env);
#endif
+#endif
}
/* Allocate a new translation block. Flush the translation buffer if
--
1.7.7.6
Re: [Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION
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.
Andreas
>
> Signed-off-by: Juan Quintela
> ---
> exec.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/exec.c b/exec.c
> index 0607c9b..cba333f 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -650,7 +650,7 @@ void cpu_exec_init_all(void)
> #endif
> }
>
> -#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
> +#if !defined(CONFIG_USER_ONLY)
>
> static int cpu_common_post_load(void *opaque, int version_id)
> {
> @@ -717,11 +717,13 @@ void cpu_exec_init(CPUArchState *env)
> #if defined(CONFIG_USER_ONLY)
> cpu_list_unlock();
> #endif
> -#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
> +#if !defined(CONFIG_USER_ONLY)
> vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env);
> +#if defined(CPU_SAVE_VERSION)
> register_savevm(NULL, "cpu", cpu_index, CPU_SAVE_VERSION,
> cpu_save, cpu_load, env);
> #endif
> +#endif
> }
>
> /* Allocate a new translation block. Flush the translation buffer if
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION
Andreas Färber 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 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.
Re: [Qemu-devel] [PATCH 01/35] vmstate: Simplify test for CPU_SAVE_VERSION
Am 04.05.2012 13:59, schrieb Juan Quintela: > Andreas Färber 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
