From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MRYVO-0008AK-JM
	for qemu-devel@nongnu.org; Thu, 16 Jul 2009 17:28:42 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MRYVJ-00089e-Oi
	for qemu-devel@nongnu.org; Thu, 16 Jul 2009 17:28:41 -0400
Received: from [199.232.76.173] (port=60812 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MRYVJ-00089b-LG
	for qemu-devel@nongnu.org; Thu, 16 Jul 2009 17:28:37 -0400
Received: from mx2.redhat.com ([66.187.237.31]:33916)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <glommer@redhat.com>) id 1MRYVJ-0007SR-8V
	for qemu-devel@nongnu.org; Thu, 16 Jul 2009 17:28:37 -0400
Date: Thu, 16 Jul 2009 18:35:20 -0300
From: Glauber Costa <glommer@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] introduce on_vcpu
Message-ID: <20090716213520.GB4019@poweredge.glommer>
References: <1247590068-565-1-git-send-email-glommer@redhat.com>
	<4A5F997A.5070508@codemonkey.ws>
	<20090716212943.GA4019@poweredge.glommer>
	<4A5F9AB8.5060206@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A5F9AB8.5060206@codemonkey.ws>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, aliguori@us.ibm.com, qemu-devel@nongnu.org

On Thu, Jul 16, 2009 at 04:25:12PM -0500, Anthony Liguori wrote:
> Glauber Costa wrote:
>> Yes. Purpose of using curren_env was just to make it look more like qemu-kvm
>> But I do understand that we'll have to change it anyway for this code to
>> have any actual value, so I'm fine with using cpu_single_env.
>>   
>
> Yeah, if qemu-kvm is introduce another global current CPUState variable,  
> then the qemu-kvm code has to change :-)
>
> Since qemu-kvm keeps a thread id in CPUState, it would make more sense  
> to check whether gettid() == env->thread_id, no?
disagree.
gettid involves a syscall. current_env in qemu-kvm is a TLS variable.
probably much cheaper.