Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized

[David Engraf]

Am 25.11.2015 um 15:36 schrieb Paolo Bonzini:
> On 25/11/2015 15:04, David Engraf wrote:
> > > >
> > >
> > > No, you don't.  Who is reading iothread_locked during
> > > qemu_cond_wait_iothread?  No one, because it is a thread-local variable
> > > whose address is never taken.
> >
> > prepare_mmio_access is reading iothread_locked by using
> > qemu_mutex_iothread_locked after qemu_tcg_wait_io_event calls
> > qemu_cond_wait. All one the same thread.
>
> Sure, but who has set iothread_locked to false during the execution of
> qemu_cond_wait?  No one, because it's a thread-local variable.  If it's
> true before qemu_cond_wait, it will be true after qemu_cond_wait and you
> don't need qemu_cond_wait_iothread... unless your compiler is broken and
> doesn't generate TLS properly.

Indeed, TLS handling is broken. The address of iothread_locked is always 
the same between threads and I can see that a different thread sets 
iothread_locked to false, thus my current thread uses an invalid state. 
I will have to check why my compiler produces invalid TLS code.

David


> Can you compile cpus.c with -S and attach it?
>
> Paolo
>
> > qemu_tcg_cpu_thread_fn
> > -> qemu_tcg_wait_io_event
> >     -> qemu_cond_wait acquires the mutex
> >
> > qemu_tcg_cpu_thread_fn
> > -> tcg_exec_all -> tcg_cpu_exec -> cpu_exec
> > -> cpu_exec ends up in calling prepare_mmio_access