[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] global_mutex and multithread.
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] global_mutex and multithread. |
Date: |
Thu, 15 Jan 2015 21:27:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 15/01/2015 20:07, Mark Burton wrote:
> However - if we go this route -the current patch is only for x86.
> (apart from the fact that we still seem to land in a deadlock…)
Jan said he had it working at least on ARM (MusicPal).
> One thing I wonder - why do we need to go to the extent of mutexing
> in the TCG like this? Why can’t you simply put a mutex get/release on
> the slow path? If the core is going to do ‘fast path’ access to the
> memory, - even if that memory was IO mapped - would it matter if it
> didn’t have the mutex?
Because there is no guarantee that the memory map isn't changed by a
core under the feet of another. The TLB (in particular the "iotlb") is
only valid with reference to a particular memory map.
Changes to the memory map certainly happen in the slow path, but lookups
are part of the fast path. Even an rwlocks is too slow for a fast path,
hence the plan of going with RCU.
Paolo
- Re: [Qemu-devel] global_mutex and multithread., (continued)
Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread.,
Paolo Bonzini <=
- Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Paolo Bonzini, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Paolo Bonzini, 2015/01/15
- Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/16
- Re: [Qemu-devel] global_mutex and multithread., Jan Kiszka, 2015/01/16
- Re: [Qemu-devel] global_mutex and multithread., Frederic Konrad, 2015/01/16
- Re: [Qemu-devel] global_mutex and multithread., Mark Burton, 2015/01/16