[03/36] vmstate: unicore32 don't support cpu migration

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 target-unicore32/cpu.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

On Mon, Mar 19, 2012 at 11:57:31PM +0100, Juan Quintela wrote:
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  target-unicore32/cpu.h |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/target-unicore32/cpu.h b/target-unicore32/cpu.h
> index a3f8589..be85250 100644
> --- a/target-unicore32/cpu.h
> +++ b/target-unicore32/cpu.h
> @@ -134,8 +134,6 @@ int uc32_cpu_signal_handler(int host_signum, void *pinfo, void *puc);
>  int uc32_cpu_handle_mmu_fault(CPUUniCore32State *env, target_ulong address, int rw,
>                                int mmu_idx);
> 
> -#define CPU_SAVE_VERSION 2
> -

Would it be pretty straightforward to give this the same treatment as
the cpus in #2? Would be nice to have a migration blocker registered
rather than just continuing to allow users to try it hopelessly.

>  /* MMU modes definitions */
>  #define MMU_MODE0_SUFFIX _kernel
>  #define MMU_MODE1_SUFFIX _user
> -- 
> 1.7.7.6
> 
>

Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> On Mon, Mar 19, 2012 at 11:57:31PM +0100, Juan Quintela wrote:
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>> ---
>>  target-unicore32/cpu.h |    2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>> 
>> diff --git a/target-unicore32/cpu.h b/target-unicore32/cpu.h
>> index a3f8589..be85250 100644
>> --- a/target-unicore32/cpu.h
>> +++ b/target-unicore32/cpu.h
>> @@ -134,8 +134,6 @@ int uc32_cpu_signal_handler(int host_signum, void *pinfo, void *puc);
>>  int uc32_cpu_handle_mmu_fault(CPUUniCore32State *env, target_ulong address, int rw,
>>                                int mmu_idx);
>> 
>> -#define CPU_SAVE_VERSION 2
>> -
>
> Would it be pretty straightforward to give this the same treatment as
> the cpus in #2? Would be nice to have a migration blocker registered
> rather than just continuing to allow users to try it hopelessly.

What to do here, then?

Basically we got:
x86(32 and 64): fully supported
arm: almost completely working
others (like ppc and sparc): more devices missing than arm, but "could
work" if somebody works on them.
the rest: no hope at all of working without lot of time.

With this series I tried to simplify the code (a lot) and port to
vmstate.  Not to change behaviour (or at least the minimum possible).

Notice that we mark not migratable cpus as such (not with migration
blockers, though).


Later, Juan.

On Wed, Apr 11, 2012 at 12:09:57PM +0200, Juan Quintela wrote:
> Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > On Mon, Mar 19, 2012 at 11:57:31PM +0100, Juan Quintela wrote:
> >> Signed-off-by: Juan Quintela <quintela@redhat.com>
> >> ---
> >>  target-unicore32/cpu.h |    2 --
> >>  1 files changed, 0 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/target-unicore32/cpu.h b/target-unicore32/cpu.h
> >> index a3f8589..be85250 100644
> >> --- a/target-unicore32/cpu.h
> >> +++ b/target-unicore32/cpu.h
> >> @@ -134,8 +134,6 @@ int uc32_cpu_signal_handler(int host_signum, void *pinfo, void *puc);
> >>  int uc32_cpu_handle_mmu_fault(CPUUniCore32State *env, target_ulong address, int rw,
> >>                                int mmu_idx);
> >> 
> >> -#define CPU_SAVE_VERSION 2
> >> -
> >
> > Would it be pretty straightforward to give this the same treatment as
> > the cpus in #2? Would be nice to have a migration blocker registered
> > rather than just continuing to allow users to try it hopelessly.
> 
> What to do here, then?
> 
> Basically we got:
> x86(32 and 64): fully supported
> arm: almost completely working
> others (like ppc and sparc): more devices missing than arm, but "could
> work" if somebody works on them.
> the rest: no hope at all of working without lot of time.
> 
> With this series I tried to simplify the code (a lot) and port to
> vmstate.  Not to change behaviour (or at least the minimum possible).
> 
> Notice that we mark not migratable cpus as such (not with migration
> blockers, though).

Nevermind me. I thought the goal was to remove CPU_SAVE_VERSION to avoid
registration of old-style save/load functions as the means to remove
migration support. I was suggesting we just explicitly register the vmsd
and mark it unmigratable so migration fails right off the bat, like you did
with the others in #2

I see now that there never was a save/load here, and that this is a
CONFIG_USER_ONLY target, so registration never occurs to begin with.

> 
> 
> Later, Juan.
>