From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KM55i-0001xl-1u
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 13:59:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KM55g-0001tk-GH
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 13:59:01 -0400
Received: from [199.232.76.173] (port=36564 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KM55g-0001tW-3i
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 13:59:00 -0400
Received: from rv-out-0708.google.com ([209.85.198.244]:36494)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pureza@gmail.com>) id 1KM55f-0003Av-NR
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 13:59:00 -0400
Received: by rv-out-0708.google.com with SMTP id f25so2194192rvb.22
	for <qemu-devel@nongnu.org>; Thu, 24 Jul 2008 10:58:58 -0700 (PDT)
Message-ID: <3e1533500807241058p4b8c3011r31a426a726b622d3@mail.gmail.com>
Date: Thu, 24 Jul 2008 18:58:58 +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: <200807241702.56609.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>
	<200807241556.48810.paul@codesourcery.com>
	<3e1533500807240817l5d30643bu64a293e3116cb110@mail.gmail.com>
	<200807241702.56609.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 5:02 PM, Paul Brook <paul@codesourcery.com> wrote:
>> > 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,
>
> If by "horribly wrong" you mean won't work reliably and is just making the bug
> a bit harder to find, then it's no better then the previous change.
> It just avoids a few of the unnecessary (but harmless) invalidations.

I see.

One last try then... Would the invalidation of the original TB by
cpu_exec_nocache() solve the problem (despite being terribly
inefficient)?

Thanks,

Luis Pureza