[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50067FA3.3060107@siemens.com>
Date: Wed, 18 Jul 2012 11:19:31 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Wen Congyang <wency@...fujitsu.com>
CC: kvm list <kvm@...r.kernel.org>, qemu-devel <qemu-devel@...gnu.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Avi Kivity <avi@...hat.com>,
"Daniel P. Berrange" <berrange@...hat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Gleb Natapov <gleb@...hat.com>
Subject: Re: [PATCH 5/7 v6] introduce a new qom device to deal with panicked
event
On 2012-07-18 03:54, Wen Congyang wrote:
> At 07/06/2012 07:05 PM, Jan Kiszka Wrote:
>> On 2012-07-06 11:41, Wen Congyang wrote:
>>> If the target is x86/x86_64, the guest's kernel will write 0x01 to the
>>> port KVM_PV_PORT when it is panciked. This patch introduces a new qom
>>> device kvm_pv_ioport to listen this I/O port, and deal with panicked
>>> event according to panicked_action's value. The possible actions are:
>>> 1. emit QEVENT_GUEST_PANICKED only
>>> 2. emit QEVENT_GUEST_PANICKED and pause the guest
>>> 3. emit QEVENT_GUEST_PANICKED and poweroff the guest
>>> 4. emit QEVENT_GUEST_PANICKED and reset the guest
>>>
>>> I/O ports does not work for some targets(for example: s390). And you
>>> can implement another qom device, and include it's code into pv_event.c
>>> for such target.
>>>
>>> Note: if we emit QEVENT_GUEST_PANICKED only, and the management
>>> application does not receive this event(the management may not
>>> run when the event is emitted), the management won't know the
>>> guest is panicked.
>>>
>>> Signed-off-by: Wen Congyang <wency@...fujitsu.com>
>>> ---
>>> hw/kvm/Makefile.objs | 2 +-
>>> hw/kvm/pv_event.c | 73 +++++++++++++++++++++++++++
>>> hw/kvm/pv_ioport.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>> kvm-stub.c | 9 +++
>>> kvm.h | 3 +
>>> vl.c | 4 ++
>>> 6 files changed, 223 insertions(+), 1 deletions(-)
>>> create mode 100644 hw/kvm/pv_event.c
>>> create mode 100644 hw/kvm/pv_ioport.c
>>>
>>> diff --git a/hw/kvm/Makefile.objs b/hw/kvm/Makefile.objs
>>> index 226497a..23e3b30 100644
>>> --- a/hw/kvm/Makefile.objs
>>> +++ b/hw/kvm/Makefile.objs
>>> @@ -1 +1 @@
>>> -obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o
>>> +obj-$(CONFIG_KVM) += clock.o apic.o i8259.o ioapic.o i8254.o pv_event.o
>>> diff --git a/hw/kvm/pv_event.c b/hw/kvm/pv_event.c
>>> new file mode 100644
>>> index 0000000..d7ded37
>>> --- /dev/null
>>> +++ b/hw/kvm/pv_event.c
>>> @@ -0,0 +1,73 @@
>>> +/*
>>> + * QEMU KVM support, paravirtual event device
>>> + *
>>> + * Copyright Fujitsu, Corp. 2012
>>> + *
>>> + * Authors:
>>> + * Wen Congyang <wency@...fujitsu.com>
>>> + *
>>> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
>>> + * See the COPYING file in the top-level directory.
>>> + *
>>> + */
>>> +
>>> +#include <linux/kvm_para.h>
>>> +#include <asm/kvm_para.h>
>>> +#include <qobject.h>
>>> +#include <qjson.h>
>>> +#include <monitor.h>
>>> +#include <sysemu.h>
>>> +#include <kvm.h>
>>> +
>>> +/* Possible values for action parameter. */
>>> +#define PANICKED_REPORT 1 /* emit QEVENT_GUEST_PANICKED only */
>>> +#define PANICKED_PAUSE 2 /* emit QEVENT_GUEST_PANICKED and pause VM */
>>> +#define PANICKED_POWEROFF 3 /* emit QEVENT_GUEST_PANICKED and quit VM */
>>> +#define PANICKED_RESET 4 /* emit QEVENT_GUEST_PANICKED and reset VM */
>>> +
>>> +static int panicked_action = PANICKED_REPORT;
>>
>> Avoid global variables please when there are device states. This one is
>> unneeded anyway (and will generate warnings when build without KVM_PV_PORT).
>
> Hmm, do you mean introduce another qom device to store event action?
I think you should be fine with one device per bus binding, but those
will consist of a common event layer and just different I/O layers (for
bus registration and access).
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
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