Re: [Qemu-devel] [question] mask SIGBUS in qemu main thread

["Alex Bennée" <alex.bennee@linaro.org>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 20 November 2017 at 12:50, Alex Bennée <alex.bennee@linaro.org> wrote:
>> What exactly do you expect the main thread to do with a SIGBUS signal?
>
> For KVM, we (can) use SIGBUS for handling machine check exceptions:
> see qemu_init_sigbus() in cpus.c, where we use prctl(PR_MCE_KILL)
> to ask the host kernel to send us a SIGBUS if the memory used
> by the VM has memory corruption detected by the hardwar. This
> then lets us inform the guest (see kvm_mce_inject() in target/i386).
> (This will probably be coming to Arm KVM at some point, as part
> of the RAS extension support. See various threads in kvmarm list.)
>
> Because asynchronous signals are a pain to deal with, for the
> main thread we handle all our signals via signalfd(), which is
> why the main thread shows SIGBUS as blocked. The main thread
> will pick the signal up via the fd at some point. For KVM vcpu
> threads, the signal arrives asynchronously. See sigbus_handler()
> in cpus.c.

Well TIL ;-)

I wonder why the choice was made to re-use SIGBUS for this. I guess the
meaning is semantically the same (some hardware fault) but surprising
they are now asynchronously delivered. When it eventually arrives at the
vCPU it won't be directly tied to what tripped up the machine checking
logic to trigger? Maybe this was never always the case?

I was slightly confused seeing sigbus_handler() only mentioned once in a
sigaction call but grepping around I can now see sigfd_handler()
directly queries the sigaction for a signal before invoking the handler
which I guess makes sense.

>
> thanks
> -- PMM


--
Alex Bennée