qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event
Date: Wed, 21 Mar 2012 14:01:18 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/09/2012 04:22 PM, Marcelo Tosatti wrote:
On Thu, Mar 08, 2012 at 11:56:56AM +0000, Daniel P. Berrange wrote:
On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote:
On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
On 03/08/2012 12:15 PM, Wen Congyang wrote:
When the host knows the guest is panicked, it will set
exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
this exit_reason, we can send a event to tell management
application that the guest is panicked and set the guest
status to RUN_STATE_PANICKED.

Signed-off-by: Wen Congyang<address@hidden>
---
  kvm-all.c        |    5 +++++
  monitor.c        |    3 +++
  monitor.h        |    1 +
  qapi-schema.json |    2 +-
  qmp.c            |    3 ++-
  vl.c             |    1 +
  6 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 77eadf6..b3c9a83 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                      (uint64_t)run->hw.hardware_exit_reason);
              ret = -1;
              break;
+        case KVM_EXIT_GUEST_PANICKED:
+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;


If the management application is not aware of this event, then it will
never resume the guest, so it will appear hung.

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
know the guest CPUs have been stopped, even if it isn't aware of the
reason why, which seems fine to me.

No.  The guest is stopped, and there's no reason to suppose that the
management app will restart it.  Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is
even more visible - service will stop completely instead of being
interrupted for a bit while the guest reboots.

Hmm, so this calls for a new command line argument to control behaviour,
similar to what we do for disk werror, eg something like

   --onpanic "report|pause|stop|..."

where

  report - emit QEVENT_GUEST_PANICKED only

Should be the default.

Should we just have a mechanism to stop the guest on certain types of QMP events? For instance:

-stop-on guest-panicked,block-ioerror

Likewise, we could have a:

-quit-on guest-panicked.

In the very least, we should make what we use for rerror,werror an enumeration that's shared here.

Regards,

Anthony Liguori


  pause  - emit QEVENT_GUEST_PANICKED and pause VM
  stop   - emit QEVENT_GUEST_PANICKED and quit VM

"quit" is a better name than "stop".

This would map fairly well into libvirt, where we already have config
parameters for controlling what todo with a guest when it panics.

Regards,
Daniel






reply via email to

[Prev in Thread] Current Thread [Next in Thread]