On Mon, 27 Feb 2012 11:05:58 +0800 Wen Congyang <wency@xxxxxxxxxxxxxx> wrote: > When the host knows the guest is paniced, it will set > exit_reason to KVM_EXIT_GUEST_PANIC. So if qemu receive > this exit_reason, we can send a event to tell management > application that the guest is paniced. > > Signed-off-by: Wen Congyang <wency@xxxxxxxxxxxxxx> > --- > kvm-all.c | 3 +++ > linux-headers/linux/kvm.h | 1 + > monitor.c | 3 +++ > monitor.h | 1 + > 4 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/kvm-all.c b/kvm-all.c > index c4babda..ae428ab 100644 > --- a/kvm-all.c > +++ b/kvm-all.c > @@ -1190,6 +1190,9 @@ int kvm_cpu_exec(CPUState *env) > (uint64_t)run->hw.hardware_exit_reason); > ret = -1; > break; > + case KVM_EXIT_GUEST_PANIC: > + monitor_protocol_event(QEVENT_GUEST_PANICED, NULL); > + break; The event alone is not enough, because the mngt app may miss it (eg. the panic happens before the mngt app connected to qemu). A simple way to solve this would be to also add a new RunState called guest-panic and make the transition to it (besides sending the event). A more general way would be to model this after -drive's werror/rerror options, say guest-error=report|ignore|stop. When guest-error=stop, the mngt app will get a STOP event and can check the VM runstate to know if it's guest-panic. -- 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
