From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt1A4-0005QN-OH for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:27:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt1A1-0005OC-4B for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:27:40 -0400 Received: from [199.232.76.173] (port=35850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt1A0-0005Ny-NN for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:27:36 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35073) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kt1A0-00049p-Dt for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:27:36 -0400 Date: Thu, 23 Oct 2008 12:28:57 -0200 From: Glauber Costa Message-ID: <20081023142857.GH18872@poweredge.glommer> References: <1224771556-11146-1-git-send-email-glommer@redhat.com> <1224771556-11146-7-git-send-email-glommer@redhat.com> <49008318.6050408@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49008318.6050408@us.ibm.com> Subject: [Qemu-devel] Re: [PATCH 06/32] split kqemu_init into two Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: jan.kiszka@siemens.com, jes@sgi.com, qemu-devel@nongnu.org, avi@qumranet.com, Glauber Costa , dmitry.baryshkov@siemens.com On Thu, Oct 23, 2008 at 08:58:48AM -0500, Anthony Liguori wrote: > Glauber Costa wrote: >> From: Glauber Costa >> >> we separate kqemu_init() into a part that depends on env, >> and other that does not. The later can be initialized earlier >> > > This patch seems harmless but I can't reasonably infer why this change > is necessary. What's the advantage of splitting the initialization into > two parts? > the previous version receives a CPUState parameter. If we do that, we never give the accelerator the chance to care for its own CPUState. So that's the reason behind the split: First, we kickstart the accelerator, which can suceed / fail. Later on, we overwrite the cpu_env initialization to give the accel a chance. > Regards, > > Anthony Liguori >