From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC2VU-0004HP-3a for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:43:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YC2VP-0001nA-0u for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:43:52 -0500 Received: from greensocs.com ([178.33.234.66]:52263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC2VO-0001mJ-M5 for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:43:46 -0500 Message-ID: <54B8CF40.8040602@greensocs.com> Date: Fri, 16 Jan 2015 09:43:44 +0100 From: Frederic Konrad MIME-Version: 1.0 References: <54B7958D.2040108@greensocs.com> <54B7A0B6.60903@redhat.com> <0AEC3776-A93D-4CAB-AF03-33327E16965D@greensocs.com> <54B822BF.6000401@redhat.com> <84050C1B-281B-4611-81C4-0FEE316B6759@greensocs.com> <54B833FF.9080408@redhat.com> <54B8C6CA.5080201@siemens.com> In-Reply-To: <54B8C6CA.5080201@siemens.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] global_mutex and multithread. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , Mark Burton , Paolo Bonzini Cc: mttcg@listserver.greensocs.com, Peter Maydell , qemu-devel , Alexander Graf 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 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 be= lieve Jan did=85 >>> Multithreaded TCG, or single-threaded TCG with SMP? >> He mentions SMP, - I assume thats single-threaded =85. > 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 someth= ing during the "rebase". I'll check. Thanks, Fred >>>>>> One thing I wonder - why do we need to go to the extent of mutexin= g >>>>>> in the TCG like this? Why can=92t you simply put a mutex get/relea= se on >>>>>> the slow path? If the core is going to do =91fast path=92 access t= o the >>>>>> memory, - even if that memory was IO mapped - would it matter if i= t >>>>>> didn=92t 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 lo= okups >>>>> 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 =91succeed=92 (the whee= ls >>>> dont fall off) -ether getting the old value, or the new, but not get= ting >>>> rubbish - and we still only take the mutex if we are going to make >>>> alterations to the MM itself? (I have=92t looked at the code around = that=85 >>>> 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, mo= st >>> of the work can be done with KVM so it's more or less independent fro= m >>> 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 =91dovetail=92 together= =93independently=94 - so - Jan=92s 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=92s patch to work for multi= -thread :-)) > See above regarding the potential dimension. > > Jan >