From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBjtf-0005nl-E0 for qemu-devel@nongnu.org; Thu, 15 Jan 2015 07:51:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBjta-0005CC-L4 for qemu-devel@nongnu.org; Thu, 15 Jan 2015 07:51:35 -0500 Received: from greensocs.com ([178.33.234.66]:46788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBjta-0005Bn-Ec for qemu-devel@nongnu.org; Thu, 15 Jan 2015 07:51:30 -0500 Message-ID: <54B7B7D0.3010308@greensocs.com> Date: Thu, 15 Jan 2015 13:51:28 +0100 From: Frederic Konrad 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; format=flowed 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 , mttcg@listserver.greensocs.com, qemu-devel Cc: Peter Maydell , Alexander Graf On 15/01/2015 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. > > And later on, once devices start being converted to run outside the BQL, > that can be changed to use new functions address_space_rw_unlocked / > io_mem_read_unlocked / io_mem_write_unlocked. Something like that is > already visible at https://github.com/bonzini/qemu/commits/rcu (ignore > patches after "kvm: Switch to unlocked MMIO"). > > Paolo > > > Hi Paolo, Thanks for the reply. As I understand the idea of Jan is to unlock the global_mutex during tcg execution. Is that right? So that means it's currently not the case and we won't be able to run two TCG threads at the same time? About the RCU, is there a lot of device which change the memory map? Thanks, Fred