Paul Brook wrote:
>> 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.

But to calculate the former, you need the latter again. I wonder if it
wouldn't be more efficient and flexible to specify a terminating PC
instead of an instruction count. Wouldn't that make cpu_io_recompile
independent of icount_decr and, thus, use_icount?

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

OK, understood.

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

Watchpoints, specifically guest-injected ones, require deterministic
exception delivery as well. So I would like to reuse existing
infrastructure that already solved a similar problem.

Jan