From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: BUG: commit 50a2c6e breaks KVM/ARM (reset/init vcpu order) Date: Mon, 26 May 2014 23:04:36 +0200 Message-ID: <5383AC64.5090201@suse.de> References: <20140526091813.GA31431@lvm> <53830F7A.3060306@redhat.com> <5383100C.3030807@suse.de> <53831565.6060401@suse.de> <538317F0.4010907@suse.de> <53833547.30300@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]:49771 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbaEZVEl (ORCPT ); Mon, 26 May 2014 17:04:41 -0400 In-Reply-To: <53833547.30300@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 26.05.14 14:36, Andreas F=E4rber wrote: > Am 26.05.2014 12:31, schrieb Alexander Graf: >> 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 r= ealize >>>> with reset? I would really prefer to ensure we're doing the same t= hing >>>> 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 n= ot >>> designed for zero'ing things, so there's a mix of data fields and >>> pointers without clear separation to allow memset(), and I have nei= ther >>> 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 r= eset >>> 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= =20 consistent across all targets :). As a nice bonus, nobody can claim QOM= =20 broke their code because the code flow won't change with step 2 ;). Alex