Re: [Qemu-devel] [PATCH 03/36] vmstate: unicore32 don't support cpu migration

[Michael Roth]

On Wed, Apr 11, 2012 at 12:09:57PM +0200, Juan Quintela wrote:
> Michael Roth <address@hidden> wrote:
> > On Mon, Mar 19, 2012 at 11:57:31PM +0100, Juan Quintela wrote:
> >> Signed-off-by: Juan Quintela <address@hidden>
> >> ---
> >>  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.
>