On Mon, Feb 18, 2013 at 09:02:55PM +0100, Andreas Färber wrote:
> Am 18.02.2013 20:57, schrieb Eduardo Habkost:
> > On Mon, Feb 18, 2013 at 08:42:28PM +0100, Andreas Färber wrote:
> >> In comparison to DeviceClass::vmsd, CPU VMState is split in two,
> >> "cpu_common" and "cpu", and uses cpu_index as instance_id instead of -1.
> >> Therefore add a CPU-specific CPUClass::vmsd field.
> >>
> >> Unlike the legacy CPUArchState registration, rather register CPUState.
> >>
> >> Signed-off-by: Juan Quintela <quint...@redhat.com>
> >> Signed-off-by: Andreas Färber <afaer...@suse.de>
> >> ---
> > [...]
> >> @@ -266,6 +268,7 @@ CPUState *qemu_get_cpu(int index)
> >> void cpu_exec_init(CPUArchState *env)
> >> {
> >> CPUState *cpu = ENV_GET_CPU(env);
> >> + CPUClass *cc = CPU_GET_CLASS(cpu);
> >> CPUArchState **penv;
> >> int cpu_index;
> >>
> >> @@ -290,11 +293,15 @@ void cpu_exec_init(CPUArchState *env)
> >> #if defined(CONFIG_USER_ONLY)
> >> cpu_list_unlock();
> >> #endif
> >> -#if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
> >> vmstate_register(NULL, cpu_index, &vmstate_cpu_common, env);
> >
> > Now vmstate_cpu_common is registered even if CPU_SAVE_VERSION isn't
> > defined and cc->vmsd is NULL. Is this intentional?
>
> Kind of, this was adopted from Juan's series. Apart from alpha and
> openrisc, which are fixed later in this series, I had taken care to mark
> all unmigratable targets as such via dc->vmsd. Thus I don't see any harm
> in it. We could go 100% safe and first mark alpha and openrisc as
> unmigratable, then do these changes and some patches later drop it again.
Those targets that are not yet marked as unmigratable are already broken
today, right? So I don't see any harm, either.
--
Eduardo
