From: Paolo Bonzini <pbonzini@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>,
"Keith Packard" <keithp@keithp.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Riku Voipio <riku.voipio@iki.fi>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH] Semihost SYS_READC implementation (v6)
Date: Tue, 17 Dec 2019 10:08:23 +0100 [thread overview]
Message-ID: <5a3b1155-4242-831c-8ae4-e9fb07f1cdb2@redhat.com> (raw)
In-Reply-To: <87h81zwdmw.fsf@linaro.org>
On 17/12/19 09:38, Alex Bennée wrote:
> Thread 3 (Thread 0x7f8b1959e700 (LWP 14017)):
> #0 0x00007f8b2ada900c in futex_wait_cancelable (private=0, expected=0, futex_word=0x56213f5482e8 <console+136>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1 0x00007f8b2ada900c in __pthread_cond_wait_common (abstime=0x0, mutex=0x56213f548298 <console+56>, cond=0x56213f5482c0 <console+96>) at pthread_cond_wait.c:502
> #2 0x00007f8b2ada900c in __pthread_cond_wait (cond=cond@entry=0x56213f5482c0 <console+96>, mutex=mutex@entry=0x56213f548298 <console+56>) at pthread_cond_wait.c:655
> #3 0x000056213ea31a40 in qemu_semihosting_console_inc (env=env@entry=0x56214138a680) at /home/alex/lsrc/qemu.git/hw/semihosting/console.c:151
> #4 0x000056213eab96e8 in do_arm_semihosting (env=env@entry=0x56214138a680) at /home/alex/lsrc/qemu.git/target/arm/arm-semi.c:805
> #5 0x000056213eacd521 in handle_semihosting (cs=<optimized out>) at /home/alex/lsrc/qemu.git/target/arm/helper.c:8476
> #6 0x000056213eacd521 in arm_cpu_do_interrupt (cs=<optimized out>) at /home/alex/lsrc/qemu.git/target/arm/helper.c:8522
> #7 0x000056213e9e53d0 in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5621411fe2f0) at /home/alex/lsrc/qemu.git/accel/tcg/cpu-exec.c:503
> #8 0x000056213e9e53d0 in cpu_exec (cpu=cpu@entry=0x562141381550) at /home/alex/lsrc/qemu.git/accel/tcg/cpu-exec.c:711
> #9 0x000056213e9b4f1f in tcg_cpu_exec (cpu=0x562141381550) at /home/alex/lsrc/qemu.git/cpus.c:1473
> #10 0x000056213e9b715b in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x562141381550) at /home/alex/lsrc/qemu.git/cpus.c:1781
> #11 0x000056213ef026fa in qemu_thread_start (args=<optimized out>) at /home/alex/lsrc/qemu.git/util/qemu-thread-posix.c:519
> #12 0x00007f8b2ada2fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
> #13 0x00007f8b2acd14cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>
> Thread 1 (Thread 0x7f8b1c151680 (LWP 14010)):
> #0 0x00007f8b2ada900c in futex_wait_cancelable (private=0, expected=0, futex_word=0x56213f52c7c8 <qemu_pause_cond+40>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
> #1 0x00007f8b2ada900c in __pthread_cond_wait_common (abstime=0x0, mutex=0x56213f52c8c0 <qemu_global_mutex>, cond=0x56213f52c7a0 <qemu_pause_cond>) at pthread_cond_wait.c:502
> #2 0x00007f8b2ada900c in __pthread_cond_wait (cond=cond@entry=0x56213f52c7a0 <qemu_pause_cond>, mutex=mutex@entry=0x56213f52c8c0 <qemu_global_mutex>) at pthread_cond_wait.c:655
> #3 0x000056213ef02e2b in qemu_cond_wait_impl (cond=0x56213f52c7a0 <qemu_pause_cond>, mutex=0x56213f52c8c0 <qemu_global_mutex>, file=0x56213ef43700 "/home/alex/lsrc/qemu.git/cpus.c", line=1943) at /home/alex/lsrc/qemu.git/util/qemu-thread-posix.c:173
> #4 0x000056213e9b74a4 in pause_all_vcpus () at /home/alex/lsrc/qemu.git/cpus.c:1943
> #5 0x000056213e9b74a4 in pause_all_vcpus () at /home/alex/lsrc/qemu.git/cpus.c:1923
> #6 0x000056213e9b7532 in do_vm_stop (state=RUN_STATE_SHUTDOWN, send_stop=<optimized out>) at /home/alex/lsrc/qemu.git/cpus.c:1102
> #7 0x000056213e96b8fc in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /home/alex/lsrc/qemu.git/vl.c:4473
>
> I guess my first question is why do we need a separate mutex/cond
> variable for this operation? This seems like the sort of thing that the
> BQL could protect.
No, please do not introduce more uses of the BQL from the CPU thread.
The problem seems to lie with the condition variable, not the mutex.
> Secondly if the vCPU is paused (via console or gdbstub) we need to
> unwind from our blocking position and be in a position to restart
> cleanly.
Perhaps if fifo8_is_empty(&c->fifo) the CPU could update the PC back to
the SVC instruction and enter a halted state? Perhaps with a new
CPU_INTERRUPT_* flag that would be checked in arm_cpu_has_work.
Paolo
next prev parent reply other threads:[~2019-12-17 9:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 19:26 [PATCH] Semihost SYS_READC implementation (v3) Keith Packard
2019-10-24 17:33 ` no-reply
2019-10-24 18:54 ` Paolo Bonzini
2019-10-24 22:46 ` [PATCH] Semihost SYS_READC implementation (v4) Keith Packard
2019-10-25 9:51 ` Alex Bennée
2019-10-25 16:36 ` Keith Packard
2019-10-25 16:49 ` Peter Maydell
2019-10-25 19:15 ` Keith Packard
2019-10-25 20:53 ` Peter Maydell
2019-10-25 23:18 ` Keith Packard
2019-11-04 20:42 ` [PATCH] Semihost SYS_READC implementation (v6) Keith Packard
2019-12-17 8:38 ` Alex Bennée
2019-12-17 9:08 ` Paolo Bonzini [this message]
2019-12-17 9:51 ` Alex Bennée
2019-12-17 10:04 ` Paolo Bonzini
2019-12-17 12:14 ` [RFC PATCH] semihosting: suspend recieving CPU when blocked (HACK, WIP) Alex Bennée
2019-12-17 12:22 ` Paolo Bonzini
2019-12-17 13:42 ` Alex Bennée
2019-12-17 13:48 ` Paolo Bonzini
2019-12-17 14:18 ` Alex Bennée
2019-12-17 14:39 ` Paolo Bonzini
2019-12-17 14:39 ` Paolo Bonzini
2019-12-18 17:36 ` Alex Bennée
2019-12-18 21:23 ` Paolo Bonzini
2019-11-05 5:10 ` [PATCH] Semihost SYS_READC implementation (v4) Keith Packard
2019-11-11 14:51 ` Peter Maydell
2019-11-14 15:46 ` Alistair Francis
2019-11-14 17:43 ` Keith Packard
2019-11-14 17:39 ` Keith Packard
2019-11-14 17:47 ` Peter Maydell
2019-11-14 19:20 ` Peter Maydell
2019-11-14 16:14 ` Peter Maydell
2019-11-14 18:05 ` Keith Packard
2019-11-14 18:18 ` Peter Maydell
2019-11-14 19:18 ` Richard Henderson
2019-11-14 19:29 ` Peter Maydell
2019-11-14 20:52 ` Richard Henderson
2019-11-14 21:04 ` Peter Maydell
2019-11-14 22:26 ` Keith Packard
2019-11-15 10:54 ` Peter Maydell
2019-11-15 23:40 ` Keith Packard
2019-10-25 17:02 ` Alex Bennée
2019-10-25 18:17 ` no-reply
2019-10-25 18:20 ` no-reply
2019-10-24 17:43 ` [PATCH] Semihost SYS_READC implementation (v3) no-reply
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=5a3b1155-4242-831c-8ae4-e9fb07f1cdb2@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=keithp@keithp.com \
--cc=laurent@vivier.eu \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).