Re: [Qemu-discuss] TCG execution in QEMU is stuck

[Arnabjyoti Kalita]

Thanks Peter for guiding me through this information. I was able to find
out the source of this problem when I added the -nochain feature to the
QEMU command line.

On Thu, Mar 15, 2018 at 6:06 AM, Peter Maydell <address@hidden>
wrote:

> On 15 March 2018 at 00:51, Arnabjyoti Kalita <address@hidden>
> wrote:
> > Hi all,
> >
> > I have been trying to modify the execution flow in QEMU. Briefly, at
> > certain points in my program, I have tried to reverse the direction of
> the
> > branch i.e. if the branch was taken, I have forced the branch to not be
> > taken or if the branch was not-taken, I have forced the branch to be
> taken.
> >
> > I am trying to make this work so that eventually QEMU follows this
> modified
> > path and ends up finishing the execution of the application.
> >
> > I use the TCG as accelerator when I run the application in QEMU. To test
> my
> > design such that it follows the new execution path, I am using the QEMU
> > "loadvm" command to load a previously saved snapshot.
> >
> > At a certain point in the program, I see that the TCG execution has
> stopped
> > entirely. I observed the trace logs which are shown below -
> >
> > Trace 0: 0x7f9669ee5d80 [0000000000000000/ffffffff810f6caa/0x40cab0]
> > tb_exit value is 3
> > Stopped execution of TB chain before 0x7f9669ee5d80 [ffffffff810f6caa]
> > Trace 0: 0x7f9669ee5d80 [0000000000000000/ffffffff810f6caa/0x40cab0]
> > tb_exit value is 3
> > Stopped execution of TB chain before 0x7f9669ee5c00 [ffffffff810f6cc3]
> >
> > I can see that the function tcg_qemu_tb_exec is returning the value 3.
> From
> > what I can understand, this means that the TCG code is waiting for an
> > interrupt. I am finding it hard to understand in what scenarios will the
> > TCG be waiting for an interrupt - and how can I make sure that the
> > execution does not stop. Is there some mechanism to manually override
> this
> > - since I am manually modifying the QEMU's execution flow ?
>
> You can't, and you don't want to -- this happens when the
> CPU's exit_request flag is set, meaning we need to stop and do
> something else. You can't execute further until the something
> else has been handled. This should all just work.
>
> > This problem does not arise (at just the exact same point) when I allow
> > QEMU to follow the original path.
>
> This rather suggests that any problem is in your modifications and
> is nothing to do with the exit_request functionality.
>
> You may find that the logging is clearer if you use -d nochain,
> which will stop QEMU from chaining multiple TBs together. When
> we execute chained TBs, we won't be able to log progress from
> one TB to another in the logs. So for instance if you have an
> infinite loop in the guest:
>    label:  jmp label
> the TB chains to itself, and when we execute it we will never
> return to C code (and log anything) except for "exit_request"
> situations. So depending on what your guest code is and whether
> your changes mean it now has infinite loops in it, the logging
> might be exactly what is expected to happen... If you enable
> nochain this will mean that every TB executed should be logged.
>
> thanks
> -- PMM
>