From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8AxN-0004dQ-Aw for qemu-devel@nongnu.org; Thu, 25 Jun 2015 13:28:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8AxJ-0007ae-5O for qemu-devel@nongnu.org; Thu, 25 Jun 2015 13:28:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60014 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8AxI-0007a9-Vq for qemu-devel@nongnu.org; Thu, 25 Jun 2015 13:28:53 -0400 Message-ID: <558C3A53.3000901@suse.de> Date: Thu, 25 Jun 2015 19:28:51 +0200 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <7d54c33fa2a928fd317f3a95af61f854f43ba23c.1435195913.git.zhugh.fnst@cn.fujitsu.com> <558C33BE.8020603@redhat.com> In-Reply-To: <558C33BE.8020603@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RESEND PATCH v8 2/4] hw: add a wrapper for registering reset handler List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: chen.fan.fnst@cn.fujitsu.com, imammedo@redhat.com, Zhu Guihua , ehabkost@redhat.com, izumi.taku@jp.fujitsu.com Am 25.06.2015 um 19:00 schrieb Paolo Bonzini: > On 25/06/2015 04:17, Zhu Guihua wrote: >> Add a wrapper to specify reset order when registering reset handler, >> instead of non-obvious initiazation code ordering. >> >> Signed-off-by: Zhu Guihua >=20 > I'm sorry, this is not really acceptable. The initialization code > ordering is good because it should be okay to run reset handlers in the > same order as code is run. If there are dependencies between reset > handlers, a random integer is not a maintainable way to maintain them. >=20 > Instead, you should have a single reset handler that calls the reset > handlers in the right order; for example a qdev bus such as icc_bus > always resets children before parents. >=20 > Are you sure that you want to remove the icc_bus?... What are you > gaining exactly by doing so? >>From my view we would be gaining by making the APIC an integral part (child<>) of the CPU in a follow-up step (there's a TODO to make things link<>s). But either way the CPU's existing reset handler should be able to handle CPU/APIC interdependencies just fine, somehow. Which is what Eduardo said on v6 and v7. (Another alternative he raised was a machine init notifier, but I see no code for that after its mention on v7?) Cheers, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)