From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KM3HR-0005Oz-TP
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 12:03:01 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KM3HR-0005OX-6a
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 12:03:01 -0400
Received: from [199.232.76.173] (port=51254 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KM3HQ-0005OG-Sp
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 12:03:00 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:38077)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1KM3HQ-0006Zk-6t
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 12:03:00 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Weird behavior while using the instruction counter
Date: Thu, 24 Jul 2008 17:02:56 +0100
References: <3e1533500807240342s15e6e508kd1d49152b0892e9f@mail.gmail.com>
	<200807241556.48810.paul@codesourcery.com>
	<3e1533500807240817l5d30643bu64a293e3116cb110@mail.gmail.com>
In-Reply-To: <3e1533500807240817l5d30643bu64a293e3116cb110@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <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: qemu-devel@nongnu.org
Cc: Luis Pureza <pureza@student.dei.uc.pt>

> > 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.

Paul