All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, Qemu Developers <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Holding the BQL for emulate_ppc_hypercall
Date: Mon, 24 Oct 2016 15:41:18 +0100	[thread overview]
Message-ID: <87a8dtkdwx.fsf@linaro.org> (raw)

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

             reply	other threads:[~2016-10-24 14:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 14:41 Alex Bennée [this message]
2016-10-24 14:44 ` [Qemu-devel] Holding the BQL for emulate_ppc_hypercall Alex Bennée
2016-10-25  2:47   ` David Gibson
2016-10-25  8:36     ` Alex Bennée
2016-10-25  3:43 ` Nikunj A Dadhania
2016-10-25  8:39   ` Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8dtkdwx.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.