[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F6A257E.20600@redhat.com>
Date: Wed, 21 Mar 2012 14:01:18 -0500
From: Anthony Liguori <anthony@...emonkey.ws>
To: Marcelo Tosatti <mtosatti@...hat.com>
CC: "Daniel P. Berrange" <berrange@...hat.com>,
kvm list <kvm@...r.kernel.org>,
Jan Kiszka <jan.kiszka@...mens.com>,
qemu-devel <qemu-devel@...gnu.org>,
Gleb Natapov <gleb@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Avi Kivity <avi@...hat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked
event
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<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.
>>
>> 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
>
>
--
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/
Powered by blists - more mailing lists