From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvSJn-0007m4-1m for qemu-devel@nongnu.org; Sat, 06 Jul 2013 09:14:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvSJm-0004UI-7a for qemu-devel@nongnu.org; Sat, 06 Jul 2013 09:14:26 -0400 Received: from cantor2.suse.de ([195.135.220.15]:54859 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvSJl-0004U8-UO for qemu-devel@nongnu.org; Sat, 06 Jul 2013 09:14:26 -0400 Message-ID: <51D8182C.30207@suse.de> Date: Sat, 06 Jul 2013 15:14:20 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1373070978-11966-1-git-send-email-agraf@suse.de> <1373070978-11966-4-git-send-email-agraf@suse.de> <51D81031.2080703@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 3/9] linux-user: Don't reset a new thread's CPU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Eduardo Habkost , Riku Voipio , Alexander Graf , qemu-devel@nongnu.org, Anthony Liguori , Igor Mammedov Am 06.07.2013 14:44, schrieb Peter Maydell: > On 6 July 2013 13:40, Andreas F=C3=A4rber wrote: >> softmmu would do it after the future QMP qom-set phase. The mess there >> is reset handler registration order: We cannot have most CPUs register= a >> reset handler themselves yet because some machines (including most ARM >> ones) register reset handlers to tweak registers before the CPU would >> have reset in that future scenario. >=20 > I'm not really a fan of that "use reset handler to simulate > bootloader firmware" code, so if you have a cleaner solution > to suggest I'd be happy to move to that. I once suggested a secondary reset hook in CPUClass, to be invoked from CPUClass::reset, that boards could set to piggy-back initializations, but IIRC Anthony didn't like that. For PReP I am trying to avoid NIP tweaking sneaking in with the ELF loading requests since I know how hard it'll be to keep working. Andreas > (if the cleaner solution is "provide a firmware blob for > all boards" that might be too much work though :-)) >=20 > -- PMM --=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