Re: [Qemu-devel] global_mutex and multithread.

[Mark Burton]

> On 16 Jan 2015, at 09:07, Jan Kiszka <address@hidden> wrote:
> 
> 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?
> 

No - we just decided to stop pressing the button…
I think this is the ‘x86 on ARM’ issue ? - our plan is to get ARM of x86 
working (or that class), and the worry about the other way round.

I dont see why SMP ARM on X86 wouldn’t work with your patch?

Cheers

Mark.

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


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

        +33 (0)603762104
        mark.burton