Re: [Qemu-devel] Re: [4799] Add instruction counter.

[Paul Brook <paul@codesourcery.com>]

> On the first glance this function looked like it could serve as an
> alternative to SSTEP_INTERNAL and provide the required roll-back on
> watchpoint hit. But looking closer I realized that icount_decr is only
> maintained if use_icount is set.

I'm fairly sure limiting the length of the TB and actual instruction counting 
are largely independent. IIUC you only need the former.

> I do not yet get why you were forced to go a different path for
> cpu_io_recompile, ie. rebuilding and (re-executing?) the whole TB up to
> the instruction that caused the IO access instead of just regenerating a
> single-insn TB for that purpose. Is it more efficient?

Generating a single insn IO TB is a good idea for resolving the current fault. 
This is what the comment at the end of cpu_io_recompile is referring to.

Regenerating a truncated version of the original version of the TB is 
important for subsequent execution of that block.  MMIO accesses occur 
frequently in loops when the guest is checking status bits or accessing a 
FIFO.  Recompiling the TB means that subsequent accesses complete with 
minimal overhead. If we didn't recompile then every access would incur a 
(very expensive) trap+unwind+singlestep.

The type of access can't be determined statically (it's a property of the 
address being accesses, not the instruction itself). However I'd expect that 
most accesses always access wither RAM or MMIO spaces in practice, so 
recompiling when we see an IO access is a reasonable compromise.

> But if use_icount is off by default, I guess this doesn't come for free
> either... 

See above. cpu_io_recompile is used to get precise delivery of interrupts. 
This is required for but not dependent on having deterministic timing (i.e. 
use_icount).

Paul