From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WosBh-0007h1-8Q for qemu-devel@nongnu.org; Mon, 26 May 2014 06:31:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WosBb-0007in-7d for qemu-devel@nongnu.org; Mon, 26 May 2014 06:31:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51220 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WosBb-0007hD-21 for qemu-devel@nongnu.org; Mon, 26 May 2014 06:31:19 -0400 Message-ID: <538317F0.4010907@suse.de> Date: Mon, 26 May 2014 12:31:12 +0200 From: Alexander Graf MIME-Version: 1.0 References: <20140526091813.GA31431@lvm> <53830F7A.3060306@redhat.com> <5383100C.3030807@suse.de> <53831565.6060401@suse.de> In-Reply-To: <53831565.6060401@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org Cc: Peter Maydell , kvm@vger.kernel.org, Paolo Bonzini , Guan Xuetao , Christoffer Dall , Richard Henderson On 26.05.14 12:20, Andreas F=E4rber wrote: > Am 26.05.2014 11:57, schrieb Alexander Graf: >> Any reason we're so incredibly inconsistent in what we do during reali= ze >> 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 =3D CPU(dev); >> target-alpha/cpu.c- AlphaCPUClass *acc =3D 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 mome= nt. > > 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? Then let's prepare for that step and make at least all targets that do=20 call cpu_reset call it after init_vcpu(). Alex