From: Alexander Graf Subject: Re: BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order) Date: Mon, 26 May 2014 12:31:12 +0200 Message-ID: <538317F0.4010907@suse.de> References: <20140526091813.GA31431@lvm> <53830F7A.3060306@redhat.com> <5383100C.3030807@suse.de> <53831565.6060401@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Paolo Bonzini , Christoffer Dall , kvm@vger.kernel.org, Peter Maydell , Richard Henderson , Guan Xuetao To: =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org Return-path: Received: from cantor2.suse.de ([195.135.220.15]:39155 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbaEZKbR (ORCPT ); Mon, 26 May 2014 06:31:17 -0400 In-Reply-To: <53831565.6060401@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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 rea= lize >> with reset? I would really prefer to ensure we're doing the same thi= ng >> 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(de= v); >> 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 neith= er > a working alpha test image nor the time to investigate this at the mo= ment. > > 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 res= et > 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