Re: [Qemu-discuss] TCG execution in QEMU is stuck
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 Maydellwrote: > On 15 March 2018 at 00:51, Arnabjyoti Kalita > 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 [/810f6caa/0x40cab0] > > tb_exit value is 3 > > Stopped execution of TB chain before 0x7f9669ee5d80 [810f6caa] > > Trace 0: 0x7f9669ee5d80 [/810f6caa/0x40cab0] > > tb_exit value is 3 > > Stopped execution of TB chain before 0x7f9669ee5c00 [810f6cc3] > > > > 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 >
Re: [Qemu-discuss] TCG execution in QEMU is stuck
On 15 March 2018 at 00:51, Arnabjyoti Kalitawrote: > 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 [/810f6caa/0x40cab0] > tb_exit value is 3 > Stopped execution of TB chain before 0x7f9669ee5d80 [810f6caa] > Trace 0: 0x7f9669ee5d80 [/810f6caa/0x40cab0] > tb_exit value is 3 > Stopped execution of TB chain before 0x7f9669ee5c00 [810f6cc3] > > 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
[Qemu-discuss] TCG execution in QEMU is stuck
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 [/810f6caa/0x40cab0] tb_exit value is 3 Stopped execution of TB chain before 0x7f9669ee5d80 [810f6caa] Trace 0: 0x7f9669ee5d80 [/810f6caa/0x40cab0] tb_exit value is 3 Stopped execution of TB chain before 0x7f9669ee5c00 [810f6cc3] 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 ? This problem does not arise (at just the exact same point) when I allow QEMU to follow the original path. I am using QEMU's version 2.11.50 and running linux -4.4.0-62-generic, the target and host architecture is x86-64. Thanks and Regards, Arnab