[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Maydell
Subject: Re: [Qemu-discuss] TCG execution in QEMU is stuck
Date: Thu, 15 Mar 2018 10:06:28 +0000

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.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]