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 <peter.mayd...@linaro.org> wrote: > On 15 March 2018 at 00:51, Arnabjyoti Kalita <akal...@cs.stonybrook.edu> > 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 >