Re: [Qemu-devel] icount and tb chaining

[Peter Maydell]

2012/1/13 James Greensky <address@hidden>:
> Sure, usually a tb chain is setup after a subsequent tb is
> found/constructed in the loop in cpu_exec when a tb returns.
> Taken/non-taken branch chaining is implemented by indicating the
> branch direction by the two least significant digits of the the
> previously returned tb. This is usually 0/1. When running icount, you
> can also get a 2 value in these least significant digits, indicating
> that the translation block was restarted due to the
> icount_decr.u16.low field being exhausted but having instructions left
> to execute in icount_extra. This 2 value falls through to tb_add_jump,
> which then updates the tb's jmp_first field, as both tb and next_tb
> refer to the same translation block. My question is why is this
> necessary, why not do nothing, and leave the previous chaining intact?

This looks suspiciously like a bug to me, although the code
is a bit opaque to me. Calling tb_add_jump() with n==2 seems like
it's not going to work since tb_set_jmp_target() is going to fall
off the end of either tb_jmp_offset[] or tb_next[], so even if we're
playing clever games with jmp_first being treatable as jmp_next[2] for
some purposes there's going to be a problem.

I thought the 2 return from a TB execution was only used as a flag
value, which would suggest that we should clear next_tb in the
'refill decrementer' code path too. I'm not sure I'm not missing
something subtle, though.

-- PMM