Re: [Qemu-discuss] Handling signal of Qemu thread

[Peter Maydell]

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