From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgqQk-0006tu-Tz for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:39:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgqQg-0006no-2z for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:39:06 -0400 Received: from [199.232.76.173] (port=33721 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgqQf-0006nV-Uo for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:39:02 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:38676) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MgqQf-0008Hh-4I for qemu-devel@nongnu.org; Thu, 27 Aug 2009 21:39:01 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7S1WG5W007867 for ; Thu, 27 Aug 2009 21:32:16 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7S1cxKP247564 for ; Thu, 27 Aug 2009 21:38:59 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7S1cwvw002929 for ; Thu, 27 Aug 2009 21:38:59 -0400 Message-ID: <4A973530.4040002@us.ibm.com> Date: Thu, 27 Aug 2009 20:38:56 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1247781328-17249-1-git-send-email-glommer@redhat.com> <4A96BF30.7090200@siemens.com> <20090828011856.GE5746@mothafucka.localdomain> In-Reply-To: <20090828011856.GE5746@mothafucka.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Glauber Costa Cc: Jan Kiszka , qemu-devel@nongnu.org, avi@redhat.com Glauber Costa wrote: > 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? > Since we already keep the tid in the vcpu structure, it seems to make more sense to ask "am I this vcpu thread" by doing gettid() == env->tid than by maintaining a new global tls variable. -- Regards, Anthony Liguori