[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 03/36] vmstate: unicore32 don't support cpu migr
From: |
Michael Roth |
Subject: |
Re: [Qemu-devel] [PATCH 03/36] vmstate: unicore32 don't support cpu migration |
Date: |
Wed, 11 Apr 2012 14:58:02 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
>