From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC1wc-0007pH-RE for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:07:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YC1wY-0005VV-Qc for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:07:50 -0500 Received: from thoth.sbs.de ([192.35.17.2]:54396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC1wY-0005V1-Hf for qemu-devel@nongnu.org; Fri, 16 Jan 2015 03:07:46 -0500 Message-ID: <54B8C6CA.5080201@siemens.com> Date: Fri, 16 Jan 2015 09:07:38 +0100 From: Jan Kiszka 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Mark Burton , Paolo Bonzini Cc: mttcg@greensocs.com, Peter Maydell , =?windows-1252?Q?KONRAD_Fr=E9d=E9ric?= , qemu-devel , Alexander Graf On 2015-01-16 08:25, Mark Burton wrote: >=20 >> 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 bel= ieve Jan did=85 >> >> Multithreaded TCG, or single-threaded TCG with SMP? >=20 > 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? >=20 >> >>>>> One thing I wonder - why do we need to go to the extent of mutexing >>>>> in the TCG like this? Why can=92t you simply put a mutex get/releas= e on >>>>> the slow path? If the core is going to do =91fast path=92 access to= the >>>>> memory, - even if that memory was IO mapped - would it matter if it >>>>> 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 loo= kups >>>> are part of the fast path. Even an rwlocks is too slow for a fast p= ath, >>>> hence the plan of going with RCU. >>> >>> Could we arrange the world such that lookups =91succeed=92 (the wheel= s >>> dont fall off) -ether getting the old value, or the new, but not gett= ing >>> 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 t= hat=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. :) >=20 > Ahh - I see ! >=20 >> >> 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, mos= t >> of the work can be done with KVM so it's more or less independent from >> what you guys have been doing so far. >=20 > 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 l= ater we can use RCU to make it work more generally (and more efficiently). >=20 > So - our only small problem is getting Jan=92s patch to work for multi-= thread :-)) See above regarding the potential dimension. Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux