Re: [Qemu-devel] BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order)

[Alexander Graf]

On 26.05.14 14:36, Andreas Färber wrote:
> Am 26.05.2014 12:31, schrieb Alexander Graf:
> > On 26.05.14 12:20, Andreas Färber wrote:
> > > Am 26.05.2014 11:57, schrieb Alexander Graf:
> > > > Any reason we're so incredibly inconsistent in what we do during realize
> > > > with reset? I would really prefer to ensure we're doing the same thing
> > > > on all targets.
> > > >
> > > >
> > > > Alex
> > > >
> > > > $ grep -R -A 3 -B 3 qemu_init_vcpu target-*
> > > > target-alpha/cpu.c-    CPUState *cs = CPU(dev);
> > > > target-alpha/cpu.c-    AlphaCPUClass *acc = ALPHA_CPU_GET_CLASS(dev);
> > > > target-alpha/cpu.c-
> > > > target-alpha/cpu.c:    qemu_init_vcpu(cs);
> > > > target-alpha/cpu.c-
> > > > target-alpha/cpu.c-    acc->parent_realize(dev, errp);
> > > > target-alpha/cpu.c-}
> > > Alpha is the main blocker for unifying CPU reset iirc. It does not
> > > implement reset at all and thus is not calling it. The struct was not
> > > designed for zero'ing things, so there's a mix of data fields and
> > > pointers without clear separation to allow memset(), and I have neither
> > > a working alpha test image nor the time to investigate this at the
> > > moment.
> > >
> > > WIP here:
> > > https://github.com/afaerber/qemu-cpu/commits/qom-cpu-alpha
> > > https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset
> > >
> > > According to my commit unicore32 is another odd sock that doesn't reset
> > > the CPU - despite implemented iirc.
> > So if we had reset, we could call
> >
> >    qemu_init_vcpu();
> >    cpu_reset()
> >
> > inside parent_realize(), right?
> That's exactly what the single commit on qom-cpu-reset does. :)

Yeah, I was indicating that we should maybe take 2 steps:

 1) Unify all targets to call init, then reset
 2) Move init and reset into the parent

That way nothing gets blocked on the CPU QOMification, yet still we are 
consistent across all targets :). As a nice bonus, nobody can claim QOM 
broke their code because the code flow won't change with step 2 ;).


Alex