Re: [Qemu-devel] global_mutex and multithread.

[Frederic Konrad]

On 16/01/2015 09:07, Jan Kiszka 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?
Hi Jan,

Actually it's what we are trying to do, running emulated CPUs in parallel.

I get a double mutex_lock error (eg: no unlock) I must have missed something
during the "rebase".
I'll check.

Thanks,
Fred

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