From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bygRL-00079G-7K for qemu-devel@nongnu.org; Mon, 24 Oct 2016 10:41:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bygRG-0001t5-W2 for qemu-devel@nongnu.org; Mon, 24 Oct 2016 10:41:27 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38839) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bygRG-0001sm-P7 for qemu-devel@nongnu.org; Mon, 24 Oct 2016 10:41:22 -0400 Received: by mail-wm0-x22f.google.com with SMTP id c78so119291572wme.1 for ; Mon, 24 Oct 2016 07:41:22 -0700 (PDT) From: Alex =?utf-8?Q?Benn=C3=A9e?= Date: Mon, 24 Oct 2016 15:41:18 +0100 Message-ID: <87a8dtkdwx.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] Holding the BQL for emulate_ppc_hypercall List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikunj A Dadhania , Bharata B Rao , David Gibson Cc: qemu-ppc@nongnu.org, Qemu Developers Hi, In the MTTCG patch set one of the big patches is to remove the requirement to hold the BQL while running code: tcg: drop global lock during TCG code execution And this broke the PPC code because emulate_ppc_hypercall can cause changes to the global state. This function just calls spapr_hypercall() and puts the results into the TCG register file. Normally spapr_hypercall() is called under the BQL in KVM as kvm_arch_handle_exit() does things with the BQL held. I blithely wrapped the called in a lock/unlock pair only to find the ppc64 check builds failed as the hypercall was made during the cc->do_interrupt() code which also holds the BQL. I'm a little confused by the nature of PPC hypercalls in TCG? Are they not all detectable at code generation time? What is the case that causes an exception to occur rather than the helper function doing the hypercall? I guess it comes down to can I avoid doing: /* If we come via cc->do_interrupt BQL may already be held */ if (!qemu_mutex_iothread_locked()) { g_mutex_lock_iothread(); env->gpr[3] = spapr_hypercall(cpu, env->gpr[3], &env->gpr[4]); g_muetx_unlock_iothread(); } else { env->gpr[3] = spapr_hypercall(cpu, env->gpr[3], &env->gpr[4]); } Any thoughts? -- Alex Bennée