From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LurlQ-0000Qf-Ca
	for qemu-devel@nongnu.org; Fri, 17 Apr 2009 13:22:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LurlL-0000OJ-Rj
	for qemu-devel@nongnu.org; Fri, 17 Apr 2009 13:22:07 -0400
Received: from [199.232.76.173] (port=57500 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LurlL-0000OE-Ii
	for qemu-devel@nongnu.org; Fri, 17 Apr 2009 13:22:03 -0400
Received: from rv-out-0708.google.com ([209.85.198.248]:16546)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LurlL-0004IL-7O
	for qemu-devel@nongnu.org; Fri, 17 Apr 2009 13:22:03 -0400
Received: by rv-out-0708.google.com with SMTP id l33so784619rvb.22
	for <qemu-devel@nongnu.org>; Fri, 17 Apr 2009 10:22:02 -0700 (PDT)
Message-ID: <49E8BAB6.2080902@codemonkey.ws>
Date: Fri, 17 Apr 2009 12:21:58 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [patch 01/11] qemu: create helper for event
	notification
References: <20090407195126.467365249@localhost.localdomain>	<20090407195442.646407971@localhost.localdomain>	<49E79AB0.2090903@us.ibm.com>
	<20090416205836.GA16259@amt.cnet>
In-Reply-To: <20090416205836.GA16259@amt.cnet>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: qemu-devel@nongnu.org

Marcelo Tosatti wrote:
> On Thu, Apr 16, 2009 at 03:53:04PM -0500, Anthony Liguori wrote:
>   
>>>      }
>>>  }
>>>   
>>>       
>> I always thought next_cpu was used here to cover an explicit race condition.
>>
>> If you're using TCG, and you get a single after running the loop, but  
>> before assigning cpu_single_env, then you'll set the interrupt exit  
>> request on the old CPU state.  You'll eventually exit I guess but you  
>> potentially have to run through multiple VCPUs.
>>
>> I'd feel more comfortable if we preserved the behavior here that we had  
>> before.
>>     
>
> Right. Patch 7 reverts to the old behaviour.
>   

We need to do this series in a way such that we aren't breaking things 
as we go along.

Regards,

Anthony Liguori