On Thu, 21 May 2015 15:48:15 +0530
Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
> On Thu, May 21, 2015 at 11:05:19AM +0200, Igor Mammedov wrote:
> > On Thu, 21 May 2015 10:32:08 +0530
> > Bharata B Rao <bhar...@linux.vnet.ibm.com> wrote:
> >
> > > Move cpu_exec_init() call from instance_init to realize. This allows
> > > any failures from cpu_exec_init() to be handled appropriately.
> > > Also add corresponding cpu_exec_exit() call from unrealize.
> > >
> > > Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com>
> > > Reviewed-by: David Gibson <da...@gibson.dropbear.id.au>
> > > ---
> > > target-ppc/translate_init.c | 9 +++++++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> > > index 52d95ce..2b72f2d 100644
> > > --- a/target-ppc/translate_init.c
> > > +++ b/target-ppc/translate_init.c
> > > @@ -8928,6 +8928,11 @@ static void ppc_cpu_realizefn(DeviceState *dev,
> > > Error **errp)
> > > return;
> > > }
> > >
> > > + cpu_exec_init(&cpu->env, &local_err);
> > > + if (local_err != NULL) {
> > > + error_propagate(errp, local_err);
> > > + return;
> > > + }
> > > cpu->cpu_dt_id = (cs->cpu_index / smp_threads) * max_smt
> > > + (cs->cpu_index % smp_threads);
> > > #endif
> > > @@ -9141,6 +9146,8 @@ static void ppc_cpu_unrealizefn(DeviceState *dev,
> > > Error **errp)
> > > opc_handler_t **table;
> > > int i, j;
> > >
> > > + cpu_exec_exit(CPU(dev));
> > > +
> > > for (i = 0; i < PPC_CPU_OPCODES_LEN; i++) {
> > > if (env->opcodes[i] == &invalid_handler) {
> > > continue;
> > > @@ -9633,8 +9640,6 @@ static void ppc_cpu_initfn(Object *obj)
> > > CPUPPCState *env = &cpu->env;
> > >
> > > cs->env_ptr = env;
> > > - cpu_exec_init(env, &error_abort);
> > > - cpu->cpu_dt_id = cs->cpu_index;
> > could you switch ppc to use CPUClass->get_arch_id()
> > it defaults to cpu_index if arch doesn't overload it.
>
> Just to be sure, your suggestion to implement ->get_arch_id() for
> ppc has nothing to do with this patch right ?
yep
>
> >
> > there were patches on list wrt migration to use
> > get_arch_id() instead of cpu_index as migration block id.
>
> Yes, saw them. AFAICS, we could have ->get_arch_id returning
> cpu_dt_id like how x86 returns apic_id when Zhu's patches make it
> upstream.
>
> Regards,
> Bharata.
>
