linux-kernel - Re: [Qemu-devel] [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]

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/