Re: [Qemu-devel] Weird behavior while using the instruction counter

[Paul Brook]

On Thursday 24 July 2008, Luis Pureza wrote:
> 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!

I think I can see how this could happen, but only when the IO instruction is 
the first instruction in the block.  For any other TB you probably get 
run+fault first.

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

You need to figure out what's actually happening. Either it's an infinite loop 
or it's not.

Instruction counter expiry and the first IO trap are both fairly expensive 
operation. Having the counter expire every few instructionswill make qemu go 
extremely slowly.  Are you sure it's not just running very slowly?

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

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.

A related issue is that we don't invalidate the cached TB if a fault occurs 
while it is being executed.

Paul