[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 15/16] tcg: Make tb_flush() thread safe
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 15/16] tcg: Make tb_flush() thread safe |
Date: |
Wed, 21 Sep 2016 20:22:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
On 21/09/2016 19:37, Emilio G. Cota wrote:
> On Wed, Sep 21, 2016 at 18:19:26 +0200, Paolo Bonzini wrote:
>>
>>
>> On 21/09/2016 18:05, Emilio G. Cota wrote:
>>>>> + tb_lock();
>>>>> +
>>>>> + /* If it's already been done on request of another CPU,
>>>>> + * just retry.
>>>>> + */
>>>>> + if (atomic_read(&tcg_ctx.tb_ctx.tb_flush_count) != tb_flush_req) {
>>>>> + goto done;
>>> tb_flush_count is always accessed with tb_lock held, right? If so, I don't
>>> see a reason to access it with atomic_read/set.
>>
>> tb_flush accesses it outside tb_lock. Technically this one you're
>> quoting need not use atomic_read, but others need to.
>
> Sorry for being thick, but when does tb_flush not own tb_lock?
> (I'm assuming we're talking only user-mode, since full-system has
> for now empty tb_lock/unlock helpers.)
When called from gdbstub I think it doesn't (and for system-mode in
other cases too, so better be ready anyway).
Paolo
[Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_exec_start/end, Paolo Bonzini, 2016/09/19
Re: [Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_exec_start/end, Emilio G. Cota, 2016/09/21
Re: [Qemu-devel] [PATCH 16/16] cpus-common: lock-free fast path for cpu_exec_start/end, Paolo Bonzini, 2016/09/22
[Qemu-devel] [PATCH 14/16] cpus-common: Introduce async_safe_run_on_cpu(), Paolo Bonzini, 2016/09/19
Re: [Qemu-devel] [PATCH v7 00/16] cpu-exec: Safe work in quiescent state, no-reply, 2016/09/19