From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Richard Henderson <rth@twiddle.net>,
"open list:Overall" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] tcg: handle EXCP_ATOMIC exception properly
Date: Fri, 10 Feb 2017 12:13:19 +0000 [thread overview]
Message-ID: <871sv6xmzk.fsf@linaro.org> (raw)
In-Reply-To: <20170210014519.12413-1-bobby.prani@gmail.com>
Pranith Kumar <bobby.prani@gmail.com> writes:
> The current method of executing atomic code in a guest uses
> cpu_exec_step_atomic() from the outermost loop. This causes an abort()
> when single stepping over atomic code since debug exception longjmp
> will point to the the setlongjmp in cpu_exec(). Another issue with
> this mechanism is that the flags which were set in atomic execution
> will be lost since we do not call cpu_exec_enter().
I should not the original patch (which is still in my tree so I guess I
should squash it) says:
The patch enables handling atomic code in the guest. This should be
preferably done in cpu_handle_exception(), but the current assumptions
regarding when we can execute atomic sections cause a deadlock.
> The following patch moves atomic exception handling to the exception
> handler where all these issues are taken care of. The change in
> start_exclusive() is necessary since now the cpu in atomic execution
> will have its running flag set, but we do not want to count it as
> pending.
>
> Thanks to Alex for helping me debug the issue.
>
> CC: Alex Bennée <alex.bennee@linaro.org>
> CC: Richard Henderson <rth@twiddle.net>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> ---
> cpu-exec.c | 2 ++
> cpus-common.c | 2 +-
> cpus.c | 4 ----
> 3 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/cpu-exec.c b/cpu-exec.c
> index b0ddada8c1..dceacfc5dd 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -427,6 +427,8 @@ static inline bool cpu_handle_exception(CPUState *cpu, int *ret)
> *ret = cpu->exception_index;
> if (*ret == EXCP_DEBUG) {
> cpu_handle_debug_exception(cpu);
> + } else if (*ret == EXCP_ATOMIC) {
> + cpu_exec_step_atomic(cpu);
> }
> cpu->exception_index = -1;
> return true;
> diff --git a/cpus-common.c b/cpus-common.c
> index 59f751ecf9..7b859752ea 100644
> --- a/cpus-common.c
> +++ b/cpus-common.c
> @@ -192,7 +192,7 @@ void start_exclusive(void)
> smp_mb();
> running_cpus = 0;
> CPU_FOREACH(other_cpu) {
> - if (atomic_read(&other_cpu->running)) {
> + if (atomic_read(&other_cpu->running) &&
> !qemu_cpu_is_self(other_cpu)) {
The comment above reads:
Must only be called from outside cpu_exec.
So we need to revise this comment. Is this really a limitation or was it
originally the design goal?
> other_cpu->has_waiter = true;
> running_cpus++;
> qemu_cpu_kick(other_cpu);
> diff --git a/cpus.c b/cpus.c
> index e1b82bcd49..981f23d52b 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1461,10 +1461,6 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
> */
> g_assert(cpu->halted);
> break;
> - case EXCP_ATOMIC:
> - qemu_mutex_unlock_iothread();
> - cpu_exec_step_atomic(cpu);
> - qemu_mutex_lock_iothread();
> default:
> /* Ignore everything else? */
> break;
--
Alex Bennée
next prev parent reply other threads:[~2017-02-10 12:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-10 1:45 [Qemu-devel] [PATCH] tcg: handle EXCP_ATOMIC exception properly Pranith Kumar
2017-02-10 4:54 ` Pranith Kumar
2017-02-10 11:34 ` Paolo Bonzini
2017-02-10 12:18 ` Alex Bennée
2017-02-10 12:29 ` Paolo Bonzini
2017-02-10 12:57 ` Alex Bennée
2017-02-10 13:59 ` Pranith Kumar
2017-02-10 12:13 ` Alex Bennée [this message]
2017-02-10 12:15 ` Paolo Bonzini
2017-02-10 12:33 ` Alex Bennée
2017-02-10 13:12 ` Paolo Bonzini
2017-02-10 14:37 ` Alex Bennée
2017-02-10 14:44 ` Paolo Bonzini
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=871sv6xmzk.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=bobby.prani@gmail.com \
--cc=crosthwaite.peter@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.