At 03/02/2012 12:51 AM, Luiz Capitulino Wrote: > On Mon, 27 Feb 2012 11:05:58 +0800 > Wen Congyang <we...@cn.fujitsu.com> 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 <we...@cn.fujitsu.com> >> --- >> 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.
OK, I will fix it. Thanks Wen Congyang > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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
