From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIoH-00082H-Bi for qemu-devel@nongnu.org; Wed, 17 Sep 2014 13:14:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUIo9-00048E-NI for qemu-devel@nongnu.org; Wed, 17 Sep 2014 13:14:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47311 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIo9-00047x-Gc for qemu-devel@nongnu.org; Wed, 17 Sep 2014 13:14:21 -0400 Message-ID: <5419C169.5060007@suse.de> Date: Wed, 17 Sep 2014 19:14:17 +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> <5419B962.7060900@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:47 schrieb Peter Maydell: > On 17 September 2014 09:40, Andreas F=C3=A4rber wrot= e: >> 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. >=20 >> 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. >=20 > I don't object to taking a pragmatic approach in the ARM code > (eg this patch). I just wanted to know if you had a preferred > direction we should be taking instead (which as you say we > kind of have to do in an incremental way). It sounds like you > don't have anything concrete in mind so maybe we should just > apply this patch. Ack. One other concern I have with this patch is the loop assuming that all following CPUs will be of type ARMCPU, but I suspect there will be other code making the same assumption - in that case Reviewed-by. > In general I suspect there are a lot of unresolved issues in > our handling of reset -- it's a complicated area which we > attempt to address in an over-simplistic way at the moment :-( Yes, having test cases for all machines would help refactor these things.= .. 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