Re: [Qemu-discuss] How do -icount flags work in QEMU TCG

[Peter Maydell]

On 21 March 2018 at 20:22, Arnabjyoti Kalita <address@hidden> wrote:
> I see that in the trace file, some of the TCG blocks seem to be translated
> more than once -
>
> ( NOTE: I am not using the TB Cache/Hash Table and have managed to disable
> it in the QEMU code )
>
> IN:
> 0xffffffff81061fd0:             nopl     (%rax, %rax)
> 0xffffffff81061fd5:             pushq    %rbp
> 0xffffffff81061fd6:             movq     0x10a00fb(%rip), %rax
> 0xffffffff81061fdd:             movq     %rsp, %rbp
> 0xffffffff81061fe0:             movl     0xf0(%rax), %eax
> 0xffffffff81061fe6:             movl     %eax, %eax
> 0xffffffff81061fe8:             popq     %rbp
> 0xffffffff81061fe9:             retq
>
> ----------------
> IN:
> 0xffffffff81061fe0:             movl     0xf0(%rax), %eax
> 0xffffffff81061fe6:             movl     %eax, %eax
> 0xffffffff81061fe8:             popq     %rbp
> 0xffffffff81061fe9:             retq
>
> ----------------
> IN:
> 0xffffffff81061fe0:             movl     0xf0(%rax), %eax
>
>
> ----------------
> IN:
> 0xffffffff81061fe6:             movl     %eax, %eax
> 0xffffffff81061fe8:             popq     %rbp
> 0xffffffff81061fe9:             retq
>
> The above example shows one TCG block that has been translated 4 times.
> Does this mean the execution gets interrupted in between ? Atleast the
> translation looked to be complete.

We only ever enter TBs from the top, so if code jumps to or restarts
at a PC value partway through an existing TB then we will treat
it as a new TB starting at whatever that PC value is. That's what's
happened here.

I can't say from the logs how this has happened, but possibilities:
 * the icount count ran out partway through a second or later
   reexecution of the block and so we effectively split it in two
 * we took a guest MMU fault on one of the memory accesses,
   which was handled and resulted in execution resuming on the
   memory access insn
 * one of the loads or stores was to an emulated device. icount
   only ever does IO on the final insn of a TB. We translate code
   assuming loads/stores aren't IO, and then if at runtime we
   find that one is to an IO device, we stop execution of the TB
   there, and generate a stub TB with just the IO insn. (I think
   that's how it works, anyway.)
 * the guest code execution flow jumped into an insn that happened
   to be in the middle of this TB

thanks
-- PMM