From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt1Mz-0002oL-TU for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:41:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt1My-0002mf-4j for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:41:01 -0400 Received: from [199.232.76.173] (port=36234 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt1Mx-0002mV-RA for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:40:59 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:23236) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kt1Mw-0001Yi-CK for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:40:59 -0400 Message-ID: <49008CF1.3060008@siemens.com> Date: Thu, 23 Oct 2008 16:40:49 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1224771556-11146-1-git-send-email-glommer@redhat.com> <1224771556-11146-23-git-send-email-glommer@redhat.com> <49008879.6080502@us.ibm.com> <20081023143725.GJ18872@poweredge.glommer> In-Reply-To: <20081023143725.GJ18872@poweredge.glommer> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 22/32] add next_cpu_index Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Anthony Liguori , jes@sgi.com, qemu-devel@nongnu.org, avi@qumranet.com, Glauber Costa , dmitry.baryshkov@siemens.com Glauber Costa wrote: > On Thu, Oct 23, 2008 at 09:21:45AM -0500, Anthony Liguori wrote: >> Glauber Costa wrote: >>> From: Glauber Costa >>> >>> separate the logic for calculating the next cpu index >>> from cpu creation. It will allow others to query what's >>> the next cpu index to be created before cpu creation. >>> >> What is this useful for? > In earlier versions of the series, I was passing the cpu_index to init_env. > So I guess it's just a die hard patch that survived the reworks. It can be dropped > now (although I believe its clearer this way). Why not keep track of the last assigned cpu_index in a global or static variable? That should be clearer and avoids the iteration (which is basically a count-how-many-cpus-we-already-have loop). Jan > >> Regards, >> >> Anthony Liguori >> >>> Signed-off-by: Glauber Costa >>> --- >>> exec.c | 22 ++++++++++++++-------- >>> 1 files changed, 14 insertions(+), 8 deletions(-) >>> >>> diff --git a/exec.c b/exec.c >>> index 80b8a78..7fe7eeb 100644 >>> --- a/exec.c >>> +++ b/exec.c >>> @@ -526,25 +526,31 @@ static int cpu_common_load(QEMUFile *f, void *opaque, int version_id) >>> } >>> #endif >>> >>> -void cpu_exec_init(CPUState *env) >>> +int next_cpu_index(void) >>> { >>> CPUState **penv; >>> - int cpu_index; >>> + int cpu_index = 0; >>> >>> - env->next_cpu = NULL; >>> penv = &first_cpu; >>> - cpu_index = 0; >>> + >>> while (*penv != NULL) { >>> penv = (CPUState **)&(*penv)->next_cpu; >>> cpu_index++; >>> } >>> - env->cpu_index = cpu_index; >>> + return cpu_index; >>> +} >>> + >>> +void cpu_exec_init(CPUState *env) >>> +{ >>> + env->next_cpu = NULL; >>> + env->cpu_index = next_cpu_index(); >>> env->nb_watchpoints = 0; >>> - *penv = env; >>> + if (env->cpu_index == 0) >>> + first_cpu = env; >>> #if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY) >>> - register_savevm("cpu_common", cpu_index, CPU_COMMON_SAVE_VERSION, >>> + register_savevm("cpu_common", env->cpu_index, CPU_COMMON_SAVE_VERSION, >>> cpu_common_save, cpu_common_load, env); >>> - register_savevm("cpu", cpu_index, CPU_SAVE_VERSION, >>> + register_savevm("cpu", env->cpu_index, CPU_SAVE_VERSION, >>> cpu_save, cpu_load, env); >>> #endif >>> } >>> -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux