From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBkVp-00042d-9r for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:31:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBkVm-0004sg-4U for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:31:01 -0500 Received: from greensocs.com ([178.33.234.66]:47206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBkVl-0004sQ-Uv for qemu-devel@nongnu.org; Thu, 15 Jan 2015 08:30:58 -0500 Message-ID: <54B7C10F.20504@greensocs.com> Date: Thu, 15 Jan 2015 14:30:55 +0100 From: Frederic Konrad MIME-Version: 1.0 References: <54B7958D.2040108@greensocs.com> <54B7A0B6.60903@redhat.com> <54B7A124.3020300@suse.de> In-Reply-To: <54B7A124.3020300@suse.de> 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: Alexander Graf , Paolo Bonzini , mttcg@listserver.greensocs.com, qemu-devel Cc: Peter Maydell On 15/01/2015 12:14, Alexander Graf wrote: > > 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 Maybe we can put a flag in the tb to say it's being executed so tb_alloc won't try to realloc it? Maybe it's a bad idea and will be actually slower than exiting and waiting all the other cpu. Fred