From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIOH-0001sW-4J for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:47:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUIOB-0005Rt-B8 for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:47:37 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:59179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUIOB-0005Qe-45 for qemu-devel@nongnu.org; Wed, 17 Sep 2014 12:47:31 -0400 Received: by mail-la0-f41.google.com with SMTP id s18so2278940lam.28 for ; Wed, 17 Sep 2014 09:47:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5419B962.7060900@suse.de> 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> From: Peter Maydell Date: Wed, 17 Sep 2014 09:47:06 -0700 Message-ID: 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: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: Fu Wei , QEMU Developers , Christoffer Dall , Ard Biesheuvel On 17 September 2014 09:40, Andreas F=C3=A4rber wrote: > 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. 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. 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 :-( But there's a pile of other problems on the ARM QEMU todo list so as long as a change like this isn't actively working against a transition you're working towards then it will solve the immediate bug. thanks -- PMM