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: Avi Kivity
Subject: Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event
Date: Thu, 08 Mar 2012 13:52:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

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.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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