Re: BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order)

["Andreas Färber" <afaerber@suse.de>]

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. :)

Andreas

> Then let's prepare for that step and make at least all targets that do
> call cpu_reset call it after init_vcpu().
> 
> 
> Alex
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg