linux-kernel - Re: [RESEND][PATCH 2/2 v3] deal with guest panicked event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F589D8D.4030105@redhat.com>
Date:	Thu, 08 Mar 2012 13:52:45 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"Daniel P. Berrange" <berrange@...hat.com>
CC:	Wen Congyang <wency@...fujitsu.com>,
	kvm list <kvm@...r.kernel.org>,
	qemu-devel <qemu-devel@...gnu.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Gleb Natapov <gleb@...hat.com>
Subject: Re: [RESEND][PATCH 2/2 v3] deal with guest panicked event

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 <wency@...fujitsu.com>
> > > ---
> > >  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/