[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Handling signal of Qemu thread
From: |
Peter Maydell |
Subject: |
Re: [Qemu-discuss] Handling signal of Qemu thread |
Date: |
Mon, 20 Aug 2018 14:06:21 +0100 |
On 16 August 2018 at 21:22, Probir Roy <address@hidden> wrote:
> I am registering a signal handler per Qemu thread (per VCPU) and
> expecting to handle it in that thread context. But I never receive the
> signal on the Qemu thread that is causing the event, rather the signal
> is sent to parent thread context. Can you please explain the reason
> behind this? I also see that Qemu has a function called
> "kvm_eat_signals". Does it have to do anything with my issue?
Signal handling is complicated, especially when the process
has multiple threads. QEMU's strategy for it is:
* only the iothread deals with signal handling, except for
one or two signals which are specifically directed to a
particular CPU thread (notably SIG_IPI)
* other threads block all signals, so that the iothread
will handle them (this is done as part of qemu_thread_create())
* the iothread handles most signals synchronously, using signalfd():
this is done in qemu_signal_init(), and is how we handle
SIGIO, SIGALRM and SIGBUS
* SIGINT, SIGHUP, SIGTERM are handled by the iothread, asynchronously
(their handlers are set in os_setup_signal_handling())
* SIGPIPE is set to SIG_IGN, so we handle pipe-closed via the
EPIPE errno rather than via a signal
* SIG_IPI is one of the signals for specific CPU threads; so
it is blocked in the iothread, and enabled in CPU threads
* kvm_eat_signals() is specifically to handle SIG_IPI, and
affects no other signal -- if the kernel returned control
to QEMU because of a pending signal on this CPU thread,
we must make sure we've processed all the SIG_IPIs before
we continue
Adding support for a new usage of signals to this design is
complicated: depending on what is going on, it might be best
handled asynchronously in the iothread, synchronously in the
iothread, or per CPU thread. What exactly are you trying to do
with your new signal ?
thanks
-- PMM