From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgq7O-00034z-A3 for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:19:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgq7J-00034n-08 for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:19:06 -0400 Received: from [199.232.76.173] (port=46794 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgq7I-00034k-TD for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:19:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34488) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mgq7I-0005By-EO for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:19:00 -0400 Date: Thu, 27 Aug 2009 22:18:56 -0300 From: Glauber Costa Message-ID: <20090828011856.GE5746@mothafucka.localdomain> References: <1247781328-17249-1-git-send-email-glommer@redhat.com> <4A96BF30.7090200@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A96BF30.7090200@siemens.com> Subject: [Qemu-devel] Re: [PATCH v3] introduce on_vcpu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com On Thu, Aug 27, 2009 at 07:15:28PM +0200, Jan Kiszka wrote: > Glauber Costa wrote: > > on_vcpu is a qemu-kvm function that will make sure that a specific > > piece of code will run on a requested cpu. We don't need that because > > we're restricted to -smp 1 right now, but those days are likely to end soon. > > > > So for the benefit of having qemu-kvm share more code with us, I'm > > introducing our own version of on_vcpu(). Right now, we either run > > a function on the current cpu, or abort the execution, because it would > > mean something is seriously wrong. > > > > As an example code, I "ported" kvm_update_guest_debug to use it, > > with some slight differences from qemu-kvm. > > > > This is probably 0.12 material > > > > Signed-off-by: Glauber Costa > > CC: Jan Kiszka > > --- > > kvm-all.c | 35 +++++++++++++++++++++++++++++------ > > 1 files changed, 29 insertions(+), 6 deletions(-) > > > > diff --git a/kvm-all.c b/kvm-all.c > > index 61194b8..07a1cdb 100644 > > --- a/kvm-all.c > > +++ b/kvm-all.c > > @@ -155,6 +155,15 @@ static void kvm_reset_vcpu(void *opaque) > > } > > } > > > > +static void on_vcpu(CPUState *env, void (*func)(void *data), void *data) > > +{ > > + if (env == cpu_single_env) { > > + func(data); > > + return; > > + } > > + abort(); > > Sorry, missed this before it went in: This abort fires already now when > kvm_update_guest_debug is invoked by the gdbstub (where cpu_single_env > is 0). This completely breaks guest debugging int kvm mode. To begin with, I believe checking for cpu_single_env is totally evil. It is unpredictable at best, since there are many places (like you just found out) that will clear it. qemu-kvm uses a TLS variable for that, to guarantee that we're in the same thread as our calling context. I like this idea. if we have io-thread disabled, we're always in the same thread, and will always execute the function directly as we used to do before on_vcpu(). I do however remember anthony bending towards issuing a gettid() instead of using a TLS var. I'm fine with both. Anthony, avi, you guys have a word here?