Re: [Qemu-devel] global_mutex and multithread.

[Mark Burton]

> On 15 Jan 2015, at 21:27, Paolo Bonzini <address@hidden> wrote:
> 
> 
> 
> 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).

yeah - our problem is when we enable multi-threads - which I dont believe Jan 
did…
Indeed - he specifically says that doesn’t work…. :-)

> 
>> 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.

Could we arrange the world such that lookups ‘succeed’ (the wheels dont fall 
off) -ether getting the old value, or the new, but not getting rubbish - and we 
still only take the mutex if we are going to make alterations to the MM itself? 
(I have’t looked at the code around that… so sorry if the question is 
ridiculous).

Cheers

Mark.

> 
> Paolo


         +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210

        +33 (0)603762104
        mark.burton