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