[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: [Qemu-devel] BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order)
Date: Mon, 26 May 2014 12:31:12 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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.


$ 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:    qemu_init_vcpu(cs);
target-alpha/cpu.c-    acc->parent_realize(dev, errp);
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:

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


inside parent_realize(), right?

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]