From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KM2ZB-0004M5-7X
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 11:17:17 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KM2Z9-0004Jh-Pv
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 11:17:16 -0400
Received: from [199.232.76.173] (port=52375 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KM2Z9-0004JY-HW
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 11:17:15 -0400
Received: from wf-out-1314.google.com ([209.85.200.169]:12578)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pureza@gmail.com>) id 1KM2Z9-0007Ct-2n
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 11:17:15 -0400
Received: by wf-out-1314.google.com with SMTP id 27so3491488wfd.4
	for <qemu-devel@nongnu.org>; Thu, 24 Jul 2008 08:17:14 -0700 (PDT)
Message-ID: <3e1533500807240817l5d30643bu64a293e3116cb110@mail.gmail.com>
Date: Thu, 24 Jul 2008 16:17:14 +0100
From: "Luis Pureza" <pureza@student.dei.uc.pt>
Sender: pureza@gmail.com
Subject: Re: [Qemu-devel] Weird behavior while using the instruction counter
In-Reply-To: <200807241556.48810.paul@codesourcery.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>
	<200807241502.53396.paul@codesourcery.com>
	<3e1533500807240742u488272b7x12c4429cbfbb9297@mail.gmail.com>
	<200807241556.48810.paul@codesourcery.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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

On Thu, Jul 24, 2008 at 3:56 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > >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.
>>
>> What about this then:
>>
>> tb2 = env->tb_jmp_cache[tb_jmp_cache_hash_func(tb->pc)];
>> if (tb2) {
>>     tb_phys_invalidate(tb2, -1);
>> }
>
> I don't think this is correct. If we have chained TBs then the jump cache
> entry may have been overwritten by a different TB.
> It's also inefficient. If we didn't get here via cpu_exec_nocache then we can
> invalidate a TB unnecessarily.
>
> Anywhere that uses tb_find_pc/cpu_restore_state is probably broken and will
> need auditing for the problems I mentioned above.

Ok. In the meanwhile, I'll stick with

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

Unless, of course, you tell me there's something horribly wrong with this :-)
Thank you,

Luis Pureza