From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kt1UA-000789-AQ for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:48:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kt1U8-00076w-S2 for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:48:25 -0400 Received: from [199.232.76.173] (port=53115 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kt1U8-00076O-68 for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:48:24 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36715) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kt1U7-0004CS-F0 for qemu-devel@nongnu.org; Thu, 23 Oct 2008 10:48:24 -0400 Date: Thu, 23 Oct 2008 12:49:43 -0200 From: Glauber Costa Message-ID: <20081023144943.GK18872@poweredge.glommer> References: <1224771556-11146-1-git-send-email-glommer@redhat.com> <1224771556-11146-25-git-send-email-glommer@redhat.com> <49007E65.20001@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49007E65.20001@siemens.com> Subject: [Qemu-devel] Re: [PATCH 24/32] check wether kqemu is enabled in open code Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, jes@sgi.com, qemu-devel@nongnu.org, avi@qumranet.com, dmitry.baryshkov@siemens.com On Thu, Oct 23, 2008 at 03:38:45PM +0200, Jan Kiszka wrote: > Glauber Costa wrote: > > kqemu is still too much spread around. The proper fix > > usually involves rethinking a bit of kqemu logic so for now, > > just check whether or not kqemu is enabled. If the kqemu accelerator > > is not present, consider it not. Otherwise, check env field. > > > > Signed-off-by: Glauber Costa > > --- > > cpu-exec.c | 2 +- > > kqemu.c | 21 +++++++++++++++++++++ > > kqemu.h | 3 +++ > > 3 files changed, 25 insertions(+), 1 deletions(-) > > > > diff --git a/cpu-exec.c b/cpu-exec.c > > index 18908d5..b47cf43 100644 > > --- a/cpu-exec.c > > +++ b/cpu-exec.c > > @@ -599,7 +599,7 @@ int cpu_exec(CPUState *env1) > > { > > if (next_tb != 0 && > > #ifdef USE_KQEMU > > - (env->kqemu_enabled != 2) && > > + (!kqemu_kernel_enabled(env)) && > > #endif > > If this ifdef is still here to foster rethinking of the check - OK :). > Otherwise I would suggest to wrap kqemu_kernel_enabled for the > !USE_KQEMU case. Yes. Ideally, it should disappear, so I see no value of "solving" it. > > > tb->page_addr[1] == -1) { > > tb_add_jump((TranslationBlock *)(next_tb & ~3), next_tb & 3, tb); > > diff --git a/kqemu.c b/kqemu.c > > index 16ebe7d..f99a4f1 100644 > > --- a/kqemu.c > > +++ b/kqemu.c > > @@ -126,6 +126,27 @@ static int is_cpuid_supported(void) > > } > > #endif > > > > +/* FIXME: Should not be needed, since ideally, QEMUAccel would avoid all kqemu tests > > + * altogether > > + */ > > +int kqemu_is_enabled(CPUState *env) > > +{ > > + if (strcasecmp(current_accel->name, "kqemu")) { > > + return 0; > > + } > > + > > + return env->kqemu_enabled; > > + > > +} > > + > > +int kqemu_kernel_enabled(CPUState *env) > > +{ > > + if (strcasecmp(current_accel->name, "kqemu")) { > > + return 0; > > + } > > + return env->kqemu_enabled == 2; > > +} > > + > > static void kqemu_update_cpuid(CPUState *env) > > { > > int critical_features_mask, features, ext_features, ext_features_mask; > > diff --git a/kqemu.h b/kqemu.h > > index cf14179..62ba1d9 100644 > > --- a/kqemu.h > > +++ b/kqemu.h > > @@ -157,6 +157,9 @@ struct kqemu_phys_mem { > > #define KQEMU_SET_PHYS_MEM _IOW('q', 5, struct kqemu_phys_mem) > > #endif > > > > +int kqemu_is_enabled(CPUState *env); > > +int kqemu_kernel_enabled(CPUState *env); > > + > > typedef struct KQEMUCPUstate { > > int kqemu_enabled; > > int last_io_time; > > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux