From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmcVS-0008V7-A4 for qemu-devel@nongnu.org; Wed, 25 Mar 2009 19:27:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmcVN-0008Nw-MP for qemu-devel@nongnu.org; Wed, 25 Mar 2009 19:27:33 -0400 Received: from [199.232.76.173] (port=39732 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmcVN-0008NW-79 for qemu-devel@nongnu.org; Wed, 25 Mar 2009 19:27:29 -0400 Received: from mx2.redhat.com ([66.187.237.31]:40203) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmcVM-0006Hb-2r for qemu-devel@nongnu.org; Wed, 25 Mar 2009 19:27:29 -0400 Date: Wed, 25 Mar 2009 20:27:11 -0300 From: Marcelo Tosatti Subject: Re: [Qemu-devel] [patch 01/10] qemu: create helper for event notification Message-ID: <20090325232711.GA5335@amt.cnet> References: <20090325224714.853788328@amt.cnet> <20090325225438.765838184@amt.cnet> <5d6222a80903251618y50ca4a63rbbb3b5e1b13b4f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5d6222a80903251618y50ca4a63rbbb3b5e1b13b4f5@mail.gmail.com> Content-Transfer-Encoding: quoted-printable 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: qemu-devel@nongnu.org On Wed, Mar 25, 2009 at 08:18:58PM -0300, Glauber Costa wrote: > > +void qemu_notify_event(void) > > +{ > > + =A0 =A0CPUState *env =3D cpu_single_env; > > + > > + =A0 =A0if (env) { > > + =A0 =A0 =A0 =A0cpu_exit(env); > > +#ifdef USE_KQEMU > > + =A0 =A0 =A0 =A0if (env->kqemu_enabled) > > + =A0 =A0 =A0 =A0 =A0 =A0kqemu_cpu_interrupt(env); > > +#endif > > + =A0 =A0 } > > =A0} >=20 > Have you tested this with kqemu?=20 Nope. > It will fire kqemu interrupts in a lot of circunstances it didn't > before. That said, I don't even think kqemu is that important, but if > it's in the tree, we don't want to introduce regressions. I'd suggest > passing a flag indicating the type of event we're notifying. It's easy > to foresee other uses for that as well. qemu_notify_event() basically means "process events handled by main_loop_wait ASAP". Maybe it needs a better name. I'll make sure there's no serious regression with kqemu. There are things like /* reset soft MMU for next block (it can currently only be set by a memory fault) */ #if defined(USE_KQEMU) #define MIN_CYCLE_BEFORE_SWITCH (100 * 1000) if (kqemu_is_ok(env) && (cpu_get_time_fast() - env->last_io_time) >=3D MIN_CYCLE_BEFORE_SWITCH) { cpu_loop_exit(); } #endif Which needs some rethinking.