qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] tcg: signal-free qemu_cpu_kick


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 3/3] tcg: signal-free qemu_cpu_kick
Date: Mon, 17 Aug 2015 11:31:30 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

On 08/14/2015 06:15 AM, Paolo Bonzini wrote:
> +    atomic_mb_set(&current_cpu, cpu);
...
> +        cpu_exit(atomic_rcu_read(&current_cpu));

Mixing java and rcu style sync to the same data structure?

> +                         * ensure tcg_exit_req is read before exit_request
> +                         * or interrupt_request.
>                           */
> +                        smp_rmb();
>                          next_tb = 0;

This I don't understand, since we've just read exit_request above, and you're
putting the barrier here?

> +        /* Ensure whatever caused the exit has reached the CPU threads before
> +         * writing exit_request.
> +         */
> +        smp_wmb();
> +        exit_request = 1;
> +        /* Ignore the CPU argument since all CPUs run in the same thread;
> +         * preempt the currently running one.  The memory barriers ensures
> +         * that other CPUs will see the request if the current CPU is
> +         * preempted.
> +         */
> +        smp_wmb();
> +        cpu_exit(atomic_rcu_read(&current_cpu));

...

> +    /* Pairs with smp_wmb in qemu_cpu_kick.  */
> +    atomic_mb_set(&exit_request, 0);
>  }

Bare barriers and java style sync to the same data structure?

>      cpu->exit_request = 1;
> +    /* Ensure cpu_exec will see the exit request after TCG has exited.  */
> +    smp_wmb();
>      cpu->tcg_exit_req = 1;
>  }

Likewise.

I find this mixing highly confusing.  I see no way to prove that it's going to
be right for non-x86.


r~



reply via email to

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