From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBr1D-0003ap-9l for qemu-devel@nongnu.org; Thu, 15 Jan 2015 15:27:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBr1A-0004El-3w for qemu-devel@nongnu.org; Thu, 15 Jan 2015 15:27:51 -0500 Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:58223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBr19-0004Ec-TR for qemu-devel@nongnu.org; Thu, 15 Jan 2015 15:27:48 -0500 Received: by mail-wi0-f182.google.com with SMTP id h11so20326164wiw.3 for ; Thu, 15 Jan 2015 12:27:47 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54B822BF.6000401@redhat.com> Date: Thu, 15 Jan 2015 21:27:43 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <54B7958D.2040108@greensocs.com> <54B7A0B6.60903@redhat.com> <0AEC3776-A93D-4CAB-AF03-33327E16965D@greensocs.com> In-Reply-To: <0AEC3776-A93D-4CAB-AF03-33327E16965D@greensocs.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] global_mutex and multithread. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton Cc: mttcg@listserver.greensocs.com, Peter Maydell , jan.kiszka@siemens.com, qemu-devel , Alexander Graf , =?windows-1252?Q?KONRAD_Fr=E9d=E9ric?= On 15/01/2015 20:07, Mark Burton wrote: > However - if we go this route -the current patch is only for x86. > (apart from the fact that we still seem to land in a deadlock…) Jan said he had it working at least on ARM (MusicPal). > 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. Paolo