qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/7 v6] introduce a new qom device to deal with


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 5/7 v6] introduce a new qom device to deal with panicked event
Date: Wed, 18 Jul 2012 11:25:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-07-18 11:19, Jan Kiszka wrote:
> 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 <address@hidden>
>>>> ---
>>>>  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 <address@hidden>
>>>> + *
>>>> + * 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).

To make this clearer: the I/O layer should embed a common state
structure of the event layer in its device state so that the event layer
can keep things like the action mode there.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux





reply via email to

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