On 3 February 2015 at 09:37, Frederic Konrad wrote:
> Actually, what we want to do is remove exit_requested global because when it
> exits
> the loop in tcg_exec_all it does exit_requested = 0, and other vcpu doesn't
> exit.
>
> This is not clear to me why we have both exit_requested global and
>
On 29/01/2015 16:52, Peter Maydell wrote:
On 16 January 2015 at 17:19, wrote:
From: KONRAD Frederic
This removes exit_request global and adds a variable in CPUState for this.
Only the flag for the first cpu is used for the moment as we are still with one
TCG thread.
--- a/cpus.c
+++ b/cpus.c
On 02/02/2015 14:12, Peter Maydell wrote:
> > In particular, you can do it while you are under the big QEMU lock.
>
> ...but this is a signal handler, so we can't guarantee that the
> thread holds the big lock.
>
> ...and if we can iterate over CPU lists in signal handlers,
> the correct approa
On 2 February 2015 at 10:03, Paolo Bonzini wrote:
>> You can't do this -- this code is a signal handler so it could
>> get run at any time including while the list of CPUs is being
>> updated. (This is why we have the exit_request flag in the
>> first place rather than just setting the exit_reques
On 29/01/2015 16:52, Peter Maydell wrote:
>> > +CPU_FOREACH(cpu) {
>> > +cpu->exit_loop_request = 1;
>> > +}
>> > }
> You can't do this -- this code is a signal handler so it could
> get run at any time including while the list of CPUs is being
> updated. (This is why we have the
On 16 January 2015 at 17:19, wrote:
> From: KONRAD Frederic
>
> This removes exit_request global and adds a variable in CPUState for this.
> Only the flag for the first cpu is used for the moment as we are still with
> one
> TCG thread.
> --- a/cpus.c
> +++ b/cpus.c
> @@ -646,10 +646,14 @@ sta
From: KONRAD Frederic
This removes exit_request global and adds a variable in CPUState for this.
Only the flag for the first cpu is used for the moment as we are still with one
TCG thread.
Signed-off-by: KONRAD Frederic
---
cpu-exec.c| 4 +---
cpus.c| 12 +---
incl
