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

2018-03-21 Thread 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 
wrote:

> 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

2018-03-15 Thread Peter Maydell
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



[Qemu-discuss] TCG execution in QEMU is stuck

2018-03-14 Thread Arnabjyoti Kalita
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