From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9p6F-0007sk-9x for qemu-devel@nongnu.org; Tue, 30 Jun 2015 02:32:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9p6C-000687-4P for qemu-devel@nongnu.org; Tue, 30 Jun 2015 02:32:55 -0400 Received: from [59.151.112.132] (port=28740 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9p6B-00064G-5f for qemu-devel@nongnu.org; Tue, 30 Jun 2015 02:32:52 -0400 Message-ID: <559237D6.8000602@cn.fujitsu.com> Date: Tue, 30 Jun 2015 14:31:50 +0800 From: Zhu Guihua MIME-Version: 1.0 References: <7d54c33fa2a928fd317f3a95af61f854f43ba23c.1435195913.git.zhugh.fnst@cn.fujitsu.com> <558C33BE.8020603@redhat.com> <558C3A53.3000901@suse.de> In-Reply-To: <558C3A53.3000901@suse.de> Content-Type: text/plain; charset="windows-1252"; format=flowed 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: =?windows-1252?Q?Andreas_F=E4rber?= , Paolo Bonzini , qemu-devel@nongnu.org Cc: chen.fan.fnst@cn.fujitsu.com, imammedo@redhat.com, ehabkost@redhat.com, izumi.taku@jp.fujitsu.com On 06/26/2015 01:28 AM, Andreas F=E4rber wrote: > 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 >> 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. >> >> 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. >> >> 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?) According to Eduardo's suggestions on v7, the simpler way is to add a=20 ordering parameter to qemu_register_reset(), so that we can ensure the order of apic reset=20 handler(apic reset must be after the other devices' reset on x86). This way will not influence the initialization code ordering expect=20 apic reset. Can we take this way? or someone have a better one? Thanks, Zhu > > Cheers, > Andreas >