[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(¤t_cpu, cpu);
...
> + cpu_exit(atomic_rcu_read(¤t_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(¤t_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~