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

[Paolo Bonzini]

On 20/08/2018 15:06, Peter Maydell wrote:
>  * 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

Also, recent kernel versions do not need to "eat" the SIG_IPI anymore.

More precisely, on older versions, SIG_IPI was temporarily unblocked
during the KVM_RUN ioctl but never delivered to the CPU thread;
therefore, kvm_eat_signal() had to remove the signal from the queue via
the sigtimedwait system call.  This was slow, especially for very large
virtual machines, due to spinlock contention in the kernel.

On newer versions, QEMU can process the SIG_IPI synchronously in the CPU
thread and set a flag that KVM_RUN reads (cpu->kvm_run->immediate_exit).
 On those new versions, the signal is never blocked and kvm_eat_signal()
does not do sigtimedwait anymore, it just resets
cpu->kvm_run->immediate_exit back to zero.

Thanks,

Paolo