Re: [Qemu-devel] global_mutex and multithread.

[Jan Kiszka]

On 2015-01-16 08:25, Mark Burton wrote:
> 
>> On 15 Jan 2015, at 22:41, Paolo Bonzini <address@hidden> wrote:
>>
>>
>>
>> On 15/01/2015 21:53, Mark Burton wrote:
>>>> 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…
>>
>> Multithreaded TCG, or single-threaded TCG with SMP?
> 
> He mentions SMP, - I assume thats single-threaded ….

Yes, I didn't patched anything towards multi-threaded SMP. Main reason:
there was no answer on how to emulated the memory models of that target
architecture over the host one which is mandatory if you let the
emulated CPUs run unsynchronized in parallel. Did this change?

> 
>>
>>>>> 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).
>>
>> That's the definition of RCU. :)  Look at the docs in
>> http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more
>> information. :)
> 
> Ahh - I see !
> 
>>
>> It's still not trivial to make it 100% correct, but at the same time
>> it's not too hard to prepare something decent to play with.  Also, most
>> of the work can be done with KVM so it's more or less independent from
>> what you guys have been doing so far.
> 
> Yes - the issue is if we end up relying on it.
> But - I see what you mean - these 2 things can ‘dovetail’ together 
> “independently” - so - Jan’s patch will be good for now, and then later we 
> can use RCU to make it work more generally (and more efficiently).
> 
> So - our only small problem is getting Jan’s patch to work for multi-thread 
> :-))

See above regarding the potential dimension.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux