On Fri, 2009-09-18 at 05:36 +0800, Marcelo Tosatti wrote: > > > > + } else if (siginfo->ssi_code == BUS_MCEERR_AR) > > > > + fprintf(stderr, "Hardware memory error!\n"); > > > > + else > > > > + fprintf(stderr, "Internal error in QEMU!\n"); > > > > > > Can you re-raise SIGBUS so you we get a coredump on non-MCE SIGBUS as > > > usual? > > > > We discuss this before. Copied below, please comment the comments > > below, :) > > > > Avi: > > (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). > > > > Huang Ying: > > 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? > > > > Andi: > > I think a suitable error message and exit would be better than a plain > > signal kill. It shouldn't look like qemu crashed due to a software > > bug. Ideally a error message in a way that it can be parsed by libvirt > > etc. and reported in a suitable way. > > > > However qemu getting killed itself is very unlikely, it doesn't > > have much memory foot print compared to the guest and other data. > > So this should be a very rare condition. > > > > Avi: > > libvirt etc. can/should wait() for qemu to terminate abnormally and > > report the reason why. However it doesn't seem there is a way to get > > extended signal information from wait(), so it looks like internal > > handling by qemu is better. > > I'm not talking about SIGBUS generated by MCE. > > What i mean is, for SIGBUS signals that are not due to MCE errors, the > current behaviour is to generate a core dump (which is useful > information for debugging). > > With your patch, qemu-kvm handles the signal, prints a message before > exiting. > > This is annoying. It seems the discussion above is about SIGBUS > initiated by MCE errors. OK. I will re-raise for SIGBUS not initiated by MCE. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
