From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBiO1-0001fN-Va for qemu-devel@nongnu.org; Thu, 15 Jan 2015 06:14:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBiNy-0005hG-IL for qemu-devel@nongnu.org; Thu, 15 Jan 2015 06:14:49 -0500 Received: from cantor2.suse.de ([195.135.220.15]:39469 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBiNy-0005gn-C6 for qemu-devel@nongnu.org; Thu, 15 Jan 2015 06:14:46 -0500 Message-ID: <54B7A124.3020300@suse.de> Date: Thu, 15 Jan 2015 12:14:44 +0100 From: Alexander Graf MIME-Version: 1.0 References: <54B7958D.2040108@greensocs.com> <54B7A0B6.60903@redhat.com> In-Reply-To: <54B7A0B6.60903@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] global_mutex and multithread. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Frederic Konrad , mttcg@listserver.greensocs.com, qemu-devel Cc: Peter Maydell On 15.01.15 12:12, Paolo Bonzini wrote: > [now with correct listserver address] > > On 15/01/2015 11:25, Frederic Konrad wrote: >> Hi everybody, >> >> In case of multithread TCG what is the best way to handle >> qemu_global_mutex? >> We though to have one mutex per vcpu and then synchronize vcpu threads when >> they exit (eg: in tcg_exec_all). >> >> Is that making sense? > > The basic ideas from Jan's patch in > http://article.gmane.org/gmane.comp.emulators.qemu/118807 still apply. > > RAM block reordering doesn't exist anymore, having been replaced with > mru_block. > > The patch reacquired the lock when entering MMIO or PIO emulation. > That's enough while there is only one VCPU thread. > > Once you have >1 VCPU thread you'll need the RCU work that I am slowly > polishing and sending out. That's because one device can change the > memory map, and that will cause a tlb_flush for all CPUs in tcg_commit, > and that's not thread-safe. You'll have a similar problem for tb_flush() if you use a single tb cache. Just introduce a big hammer function for now that IPIs all the other threads, waits until they halted, do the atomic instruction (like change the memory map or flush the tb cache), then let them continue. We can later one-by-one get rid of all callers of this. Alex