From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCS3t-0007gP-T2 for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:33:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCS3r-0003bb-4o for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:33:21 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:37267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCS3q-0003b2-UF for qemu-devel@nongnu.org; Tue, 07 Jul 2015 08:33:19 -0400 Received: by wiclp1 with SMTP id lp1so49295760wic.0 for ; Tue, 07 Jul 2015 05:33:18 -0700 (PDT) References: <1435330053-18733-1-git-send-email-fred.konrad@greensocs.com> <1435330053-18733-8-git-send-email-fred.konrad@greensocs.com> <558D6800.30306@siemens.com> <558D7185.5040401@greensocs.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <558D7185.5040401@greensocs.com> Date: Tue, 07 Jul 2015 13:33:15 +0100 Message-ID: <87mvz89mgk.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC PATCH V6 07/18] Drop global lock during TCG code execution List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Frederic Konrad Cc: mttcg@listserver.greensocs.com, peter.maydell@linaro.org, Jan Kiszka , mark.burton@greensocs.com, agraf@suse.de, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, a.spyridakis@virtualopensystems.com, pbonzini@redhat.com, alistair.francis@xilinx.com Frederic Konrad writes: > On 26/06/2015 16:56, Jan Kiszka wrote: >> On 2015-06-26 16:47, fred.konrad@greensocs.com wrote: >>> From: Jan Kiszka >>> >>> This finally allows TCG to benefit from the iothread introduction: Drop >>> the global mutex while running pure TCG CPU code. Reacquire the lock >>> when entering MMIO or PIO emulation, or when leaving the TCG loop. >>> diff --git a/translate-all.c b/translate-all.c >>> index c25b79b..ade2269 100644 >>> --- a/translate-all.c >>> +++ b/translate-all.c >>> @@ -1222,6 +1222,7 @@ void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end, >>> #endif >>> #ifdef TARGET_HAS_PRECISE_SMC >>> if (current_tb_modified) { >>> + qemu_mutex_unlock_iothread(); >>> /* we generate a block containing just the instruction >>> modifying the memory. It will ensure that it cannot modify >>> itself */ >>> @@ -1326,6 +1327,7 @@ static void tb_invalidate_phys_page(tb_page_addr_t addr, >>> p->first_tb = NULL; >>> #ifdef TARGET_HAS_PRECISE_SMC >>> if (current_tb_modified) { >>> + qemu_mutex_unlock_iothread(); >>> /* we generate a block containing just the instruction >>> modifying the memory. It will ensure that it cannot modify >>> itself */ >>> diff --git a/vl.c b/vl.c >>> index 69ad90c..2983d44 100644 >>> --- a/vl.c >>> +++ b/vl.c >>> @@ -1698,10 +1698,16 @@ void qemu_devices_reset(void) >>> { >>> QEMUResetEntry *re, *nre; >>> >>> + /* >>> + * Some device's reset needs to grab the global_mutex. So just release it >>> + * here. >> That's a property newly introduced by the patch, or how does this >> happen? In turn, are all reset handlers now fine to be called outside of >> BQL? This looks suspicious, but it's been quite a while since I last >> starred at this. >> >> Jan > Hi Jan, > > Sorry for that, it's a dirty hack :). > Some reset handler probably load stuff in the memory hence a double lock. > It will probably disappear with: > > http://thread.gmane.org/gmane.comp.emulators.qemu/345258 So I guess this patch will shrink a lot once we re-base ontop of Paolo's patches (which should be real soon now). > > Thanks, > Fred > >>> + */ >>> + qemu_mutex_unlock_iothread(); >>> /* reset all devices */ >>> QTAILQ_FOREACH_SAFE(re, &reset_handlers, entry, nre) { >>> re->func(re->opaque); >>> } >>> + qemu_mutex_lock_iothread(); >>> } >>> >>> void qemu_system_reset(bool report) >>> -- Alex Bennée