From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54023) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCSlW-0001zc-Ht for qemu-devel@nongnu.org; Tue, 07 Jul 2015 09:18:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCSlS-00008Z-Ae for qemu-devel@nongnu.org; Tue, 07 Jul 2015 09:18:26 -0400 Received: from greensocs.com ([193.104.36.180]:50940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCSlS-00008I-0t for qemu-devel@nongnu.org; Tue, 07 Jul 2015 09:18:22 -0400 Message-ID: <559BD19A.9070203@greensocs.com> Date: Tue, 07 Jul 2015 15:18:18 +0200 From: Frederic Konrad MIME-Version: 1.0 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> <87mvz89mgk.fsf@linaro.org> In-Reply-To: <87mvz89mgk.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: =?UTF-8?B?QWxleCBCZW5uw6ll?= 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 On 07/07/2015 14:33, Alex Benn=C3=A9e wrote: > 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: D= rop >>>> 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_add= r_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 mo= dify >>>> itself */ >>>> @@ -1326,6 +1327,7 @@ static void tb_invalidate_phys_page(tb_page_ad= dr_t addr, >>>> p->first_tb =3D 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 mo= dify >>>> 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; >>>> =20 >>>> + /* >>>> + * 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 lo= ck. >> 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). Yes exactly. > >> 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(); >>>> } >>>> =20 >>>> void qemu_system_reset(bool report) >>>>