From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBsAP-0007ly-UU for qemu-devel@nongnu.org; Thu, 15 Jan 2015 16:41:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBsAM-0008A2-OI for qemu-devel@nongnu.org; Thu, 15 Jan 2015 16:41:25 -0500 Received: from plane.gmane.org ([80.91.229.3]:57862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBsAM-00089n-H4 for qemu-devel@nongnu.org; Thu, 15 Jan 2015 16:41:22 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YBsAJ-00077z-R2 for qemu-devel@nongnu.org; Thu, 15 Jan 2015 22:41:19 +0100 Received: from 88-149-195-114.vps.virtuo.it ([88.149.195.114]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jan 2015 22:41:19 +0100 Received: from pbonzini by 88-149-195-114.vps.virtuo.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Jan 2015 22:41:19 +0100 From: Paolo Bonzini Date: Thu, 15 Jan 2015 22:41:05 +0100 Message-ID: <54B833F1.6070508@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit In-Reply-To: <84050C1B-281B-4611-81C4-0FEE316B6759@greensocs.com> Subject: Re: [Qemu-devel] global_mutex and multithread. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: mttcg@listserver.greensocs.com, Peter Maydell , jan.kiszka@siemens.com, Alexander Graf , =?windows-1252?Q?KONRAD_Fr=E9d=E9ric?= 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? >>> 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. :) 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. Paolo