From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KM28B-00044j-Lr
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 10:49:23 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KM28B-00044O-7n
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 10:49:23 -0400
Received: from [199.232.76.173] (port=50447 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KM28A-00044J-UB
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 10:49:22 -0400
Received: from yx-out-1718.google.com ([74.125.44.152]:27355)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pureza@gmail.com>) id 1KM28A-0002fD-RO
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 10:49:23 -0400
Received: by yx-out-1718.google.com with SMTP id 3so623018yxi.82
	for <qemu-devel@nongnu.org>; Thu, 24 Jul 2008 07:49:21 -0700 (PDT)
Message-ID: <3e1533500807240749o2de4821aw62758e51dda2dcac@mail.gmail.com>
Date: Thu, 24 Jul 2008 15:49:21 +0100
From: "Luis Pureza" <pureza@student.dei.uc.pt>
Sender: pureza@gmail.com
Subject: Fwd: [Qemu-devel] Weird behavior while using the instruction counter
In-Reply-To: <3e1533500807240742u488272b7x12c4429cbfbb9297@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3e1533500807240342s15e6e508kd1d49152b0892e9f@mail.gmail.com>
	<200807241344.35106.paul@codesourcery.com>
	<3e1533500807240654x67920d8ao55c420390f421ee3@mail.gmail.com>
	<200807241502.53396.paul@codesourcery.com>
	<3e1533500807240742u488272b7x12c4429cbfbb9297@mail.gmail.com>
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

By mistake I sent the following message to Paul Brook's private address.
Apologies for that.

Luis Pureza

---------- Forwarded message ----------
From: Luis Pureza <pureza@student.dei.uc.pt>
Date: Thu, Jul 24, 2008 at 3:42 PM
Subject: Re: [Qemu-devel] Weird behavior while using the instruction counter
To: Paul Brook <paul@codesourcery.com>


On Thu, Jul 24, 2008 at 3:02 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > No. You're assuming the IO trap occurs on the last instruction, which not
>> > true.  The problem is that cpu_exec_nocache introduces a second TB with
>> > the same lookup key(pc+flags). cpu_io_recompile (and possibly other
>> > places) assume the currently executing TB is the only tb that matches. It
>> > needs to invalidate the original TB (if it exists) as well as the
>> > uncached one.
>>
>> Obviously, you're right. I was testing with blocks of a single
>> instruction. What do you think of this:
>>
>>  if (tb != &tbs[0] && (tb - 1)->pc == tb->pc) {
>>         tb_phys_invalidate(tb - 1, -1);
>>  }
>
> No. There's no guarantee that the TBs are consecutive.

What about this then:

tb2 = env->tb_jmp_cache[tb_jmp_cache_hash_func(tb->pc)];
if (tb2) {
   tb_phys_invalidate(tb2, -1);
}

added to the same place. This way, tb_find_fast() will never return
the old TB again.

Luis Pureza