mbox series

[RFC,0/2] Improve qemu-thread support on macOS

Message ID 20181217202602.31113-1-r.bolshakov@yadro.com (mailing list archive)
Headers show
Series Improve qemu-thread support on macOS | expand

Message

Roman Bolshakov Dec. 17, 2018, 8:26 p.m. UTC
Hello,

I've hit a case where QEMU hangs not responding to anything except
SIGKILL. It turned out to be a SIGSEGV in vCPU thread that was lost by
masking all signals.

By blocking too many signals QEMU relies on undefined behaviour that
seems to work on Linux. It's documented in POSIX reference and
sigprocmask(2). Indeed signalfd(2) on Linux notes that it can't be used
to receive SIGSEGV and SIGFPE.

It's not clear what do with SIGBUS on macOS. We can't blindly unblock it
as it's used for memory preallocation.

Also the RFC adds support for thread naming on macOS. Some threads
(signalfd_compat and rcu_call) are created before debug-threads=on is
parsed and don't get their names though.

Thank you,
Roman

Roman Bolshakov (2):
  util: Implement debug-threads for macOS
  qemu-thread: Don't block SEGV, ILL and FPE

 configure                | 32 ++++++++++++++++++++++++++------
 qemu-options.hx          |  4 ++--
 util/qemu-thread-posix.c | 11 ++++++++++-
 3 files changed, 38 insertions(+), 9 deletions(-)

Comments

Peter Maydell Jan. 8, 2019, 2:53 p.m. UTC | #1
On Mon, 17 Dec 2018 at 20:46, Roman Bolshakov <r.bolshakov@yadro.com> wrote:
>
> Hello,
>
> I've hit a case where QEMU hangs not responding to anything except
> SIGKILL. It turned out to be a SIGSEGV in vCPU thread that was lost by
> masking all signals.
>
> By blocking too many signals QEMU relies on undefined behaviour that
> seems to work on Linux. It's documented in POSIX reference and
> sigprocmask(2). Indeed signalfd(2) on Linux notes that it can't be used
> to receive SIGSEGV and SIGFPE.
>
> It's not clear what do with SIGBUS on macOS. We can't blindly unblock it
> as it's used for memory preallocation.
>
> Also the RFC adds support for thread naming on macOS. Some threads
> (signalfd_compat and rcu_call) are created before debug-threads=on is
> parsed and don't get their names though.

Applied to master, thanks.

-- PMM