From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIUm-0003Cq-MO for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:54:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUIUg-0007Eb-D8 for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:54:20 -0400 Received: from cantor2.suse.de ([195.135.220.15]:46858 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIUg-0007EM-6k for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:54:14 -0400 Message-ID: <5419B962.7060900@suse.de> Date: Wed, 17 Sep 2014 18:40:02 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1409930126-28449-1-git-send-email-ard.biesheuvel@linaro.org> <1409930126-28449-5-git-send-email-ard.biesheuvel@linaro.org> <5419AEF3.8010101@suse.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 4/6] hw/arm/boot: register cpu reset handlers if using -bios List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Fu Wei , QEMU Developers , Christoffer Dall , Ard Biesheuvel Am 17.09.2014 um 18:17 schrieb Peter Maydell: > On 17 September 2014 08:55, Andreas F=C3=A4rber wrot= e: >> IIRC each machine is responsible for registering a reset hook that cal= ls >> - in most cases - cpu_reset(). >> >> The thing to look out for here is, does any machine already register a >> reset hook and would reset twice with this patch? >=20 > Probably not -- any such double-reset would already be happening > if the user passed -kernel. >=20 > So in that sense this patch won't break things, but I wasn't > sure if it's the right direction to go -- should we be fixing > all the board and/or SoC models to do the CPU reset instead? >=20 > QOM devices get reset when their bus gets reset, right? > (so everything on a bus gets reset eventually as part of > the process that starts when the top level sysbus gets reset). We avoided that by not using DeviceClass::reset but CPUClass::reset. It's a question of assuring appropriate reset ordering between CPU and devices. PowerPC needed a special reset order via hook in (what is now) MachineClass. So while I agree that CPU reset registration is not ideal and needs changing, I am not convinced that we can generally make the change and hope for the best. I wouldn't mind an incremental transition though, with arm taking the first step - still leaves the question of exact direction. If you look at x86, you will find that despite my protest against this inconsistency, the reset hook registration was moved into CPU code but none of the other targets changed alongside. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg