On 09/10/2009 12:35 PM, Andi Kleen wrote:
(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?
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.
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.
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.
(I get SIGBUS quite often running qemu from nfs and compiling a new one,
however that's a really different use case)
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
