Re: [Qemu-devel] icount and tb chaining

[Laurent Desnogues]

On Tue, Jan 17, 2012 at 8:06 PM, Laurent Desnogues
<address@hidden> wrote:
> On Tue, Jan 17, 2012 at 7:50 PM, Peter Maydell <address@hidden> wrote:
>> 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.
>
> Hmm I wonder if I didn't miss something in the discussion
> because the only call to tb_add_jmp clears the lower two
> bits so I fail to see the issue.

Hmm I knew I was missing something, forget this :-)


Laurent