On 16 August 2018 at 21:22, Probir Roy <r...@probir.info> 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