From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KLyHJ-0000FG-Kc
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 06:42:34 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KLyHG-0000ET-8I
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 06:42:31 -0400
Received: from [199.232.76.173] (port=55709 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KLyHF-0000E7-6Y
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 06:42:29 -0400
Received: from wf-out-1314.google.com ([209.85.200.170]:28456)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <pureza@gmail.com>) id 1KLyHF-00011h-QS
	for qemu-devel@nongnu.org; Thu, 24 Jul 2008 06:42:30 -0400
Received: by wf-out-1314.google.com with SMTP id 27so3358802wfd.4
	for <qemu-devel@nongnu.org>; Thu, 24 Jul 2008 03:42:27 -0700 (PDT)
Message-ID: <3e1533500807240342s15e6e508kd1d49152b0892e9f@mail.gmail.com>
Date: Thu, 24 Jul 2008 11:42:27 +0100
From: "Luis Pureza" <pureza@student.dei.uc.pt>
Sender: pureza@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [Qemu-devel] Weird behavior while using the instruction counter
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

Hi,

I'm using the instruction counter to execute N instructions at a time.
With very small values of N (say, N < 10), I observed the following
behavior:

1. A new TB is generated and execution starts there;
2. The instruction counter timer expires and cpu_exec_nocache() is called;
3. cpu_exec_nocache() generates a new TB for the same PC and starts to
execute it;
4. Some instruction inside the TB turns out to be an I/O instruction.
Thus, cpu_io_recompile() gets called
5; cpu_io_recompile() regenerates the TB and longjmps back to the
beginning of cpu_exec()
6. on cpu_exec(), tb_find_fast() returns the first TB, instead of the
one generated by cpu_io_recompile()
7. Endless loop!

Actually, for some reason beyond my comprehension, the loop is not
really infinite: after a few seconds it actually executes the block
and moves on. However, as you can imagine, this is too slow.

I think I fixed the problem by appending CF_LAST_IO to the cflags of
the TB generated by cpu_exec_nocache(). This way, cpu_io_recompile()
won't be called for this TB. Certainly not the best solution, though.

I was wondering if my thinking makes sense or am I just completely wrong :-)

Cheers,

Luis Pureza