On Wed, 2009-09-09 at 20:06 +0800, Avi Kivity wrote:
[snip]
> >
> > int kvm_init_ap(void)
> > {
> > + struct sigaction action;
> > +
> > #ifdef TARGET_I386
> > kvm_tpr_opt_setup();
> > #endif
> > qemu_add_vm_change_state_handler(kvm_vm_state_change_handler, NULL);
> >
> > signal(SIG_IPI, sig_ipi_handler);
> > +
> > + memset(&action, 0, sizeof(action));
> > + action.sa_flags = SA_SIGINFO;
> > + action.sa_sigaction = (void (*)(int, siginfo_t*, void*))sigbus_handler;
> > + sigaction(SIGBUS,&action, NULL);
> > + prctl(PR_MCE_KILL, 1, 1);
> > return 0;
> > }
> >
>
> Why do we need a SIGBUS handler? kvm vcpu threads will block and
> dequeue a SIGBUG in guest mode, so the handler will never be called, and
> we can't really handle SIGBUS in user mode.
There are two kinds of SIGBUS, corresponding to two kinds of UCR MCE.
One kind of UCR MCE is caused by user space (guest mode) read/write, and
will send SIGBUS to vcpu threads. And that will be processed by vcpu
thread sigbus handler just like SIG_IPI processing.
The other kind of UCR MCE is caused by asynchronously detected errors
(e.g. patrol scrubbing), and will send SIGBUS to main thread instead of
vcpu threads.
> (also, I if we can't handle guest-mode SIGBUS I think it would be nice
> to raise it again so the process terminates due to the SIGBUS).
For SIGBUS we can not relay to guest as MCE, we can either abort or
reset SIGBUS to SIGDFL and re-raise it. Both are OK for me. You prefer
the latter one?
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
