From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlwCZ-0000FO-1Z for qemu-devel@nongnu.org; Tue, 03 Jul 2012 02:03:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlwCW-00039V-Qk for qemu-devel@nongnu.org; Tue, 03 Jul 2012 02:03:06 -0400 Received: from [222.73.24.84] (port=27521 helo=song.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlwCW-00038H-31 for qemu-devel@nongnu.org; Tue, 03 Jul 2012 02:03:04 -0400 Message-ID: <4FF28C17.703@cn.fujitsu.com> Date: Tue, 03 Jul 2012 14:07:19 +0800 From: Wen Congyang MIME-Version: 1.0 References: <4FEAAE6E.7070302@cn.fujitsu.com> <4FEAAFFF.40401@cn.fujitsu.com> <4FEB1B06.4050309@siemens.com> <4FEBB044.1000306@cn.fujitsu.com> <4FEC153B.6040300@siemens.com> In-Reply-To: <4FEC153B.6040300@siemens.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Gleb Natapov , kvm list , qemu-devel , "linux-kernel@vger.kernel.org" , Avi Kivity , KAMEZAWA Hiroyuki At 06/28/2012 04:26 PM, Jan Kiszka Wrote: > On 2012-06-28 03:15, Wen Congyang wrote: >> At 06/27/2012 10:39 PM, Jan Kiszka Wrote: >>> On 2012-06-27 09:02, Wen Congyang wrote: >>>> When the guest is panicked, it will write 0x1 to the port KVM_PV_PORT. >>>> So if qemu reads 0x1 from this port, we can do the folloing three >>>> things according to the parameter -onpanic: >>>> 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 >>>> >>>> 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 >>>> --- >>>> kvm-all.c | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> kvm-stub.c | 9 +++++ >>>> kvm.h | 3 ++ >>>> qemu-options.hx | 15 ++++++++ >>>> vl.c | 10 +++++ >>>> 5 files changed, 138 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/kvm-all.c b/kvm-all.c >>>> index f8e4328..9494dd2 100644 >>>> --- a/kvm-all.c >>>> +++ b/kvm-all.c >>>> @@ -19,6 +19,8 @@ >>>> #include >>>> >>>> #include >>>> +#include >>>> +#include >>>> >>>> #include "qemu-common.h" >>>> #include "qemu-barrier.h" >>>> @@ -32,6 +34,9 @@ >>>> #include "bswap.h" >>>> #include "memory.h" >>>> #include "exec-memory.h" >>>> +#include "iorange.h" >>>> +#include "qemu-objects.h" >>>> +#include "monitor.h" >>>> >>>> /* This check must be after config-host.h is included */ >>>> #ifdef CONFIG_EVENTFD >>>> @@ -1931,3 +1936,99 @@ int kvm_on_sigbus(int code, void *addr) >>>> { >>>> return kvm_arch_on_sigbus(code, addr); >>>> } >>>> + >>>> +/* 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; >>>> + >>>> +static void kvm_pv_port_read(IORange *iorange, uint64_t offset, unsigned width, >>>> + uint64_t *data) >>>> +{ >>>> + *data = (1 << KVM_PV_FEATURE_PANICKED); >>>> +} >>>> + >>>> +static void panicked_mon_event(const char *action) >>>> +{ >>>> + QObject *data; >>>> + >>>> + data = qobject_from_jsonf("{ 'action': %s }", action); >>>> + monitor_protocol_event(QEVENT_GUEST_PANICKED, data); >>>> + qobject_decref(data); >>>> +} >>>> + >>>> +static void panicked_perform_action(void) >>>> +{ >>>> + switch (panicked_action) { >>>> + case PANICKED_REPORT: >>>> + panicked_mon_event("report"); >>>> + break; >>>> + >>>> + case PANICKED_PAUSE: >>>> + panicked_mon_event("pause"); >>>> + vm_stop(RUN_STATE_GUEST_PANICKED); >>>> + break; >>>> + >>>> + case PANICKED_POWEROFF: >>>> + panicked_mon_event("poweroff"); >>>> + exit(0); >>>> + break; >>>> + case PANICKED_RESET: >>>> + panicked_mon_event("reset"); >>>> + qemu_system_reset_request(); >>>> + break; >>>> + } >>>> +} >>>> + >>>> +static void kvm_pv_port_write(IORange *iorange, uint64_t offset, unsigned width, >>>> + uint64_t data) >>>> +{ >>>> + if (data == KVM_PV_PANICKED) { >>>> + panicked_perform_action(); >>>> + } >>>> +} >>>> + >>>> +static void kvm_pv_port_destructor(IORange *iorange) >>>> +{ >>>> + g_free(iorange); >>>> +} >>>> + >>>> +static IORangeOps pv_io_range_ops = { >>>> + .read = kvm_pv_port_read, >>>> + .write = kvm_pv_port_write, >>>> + .destructor = kvm_pv_port_destructor, >>>> +}; >>>> + >>>> +#if defined(KVM_PV_PORT) >>>> +void kvm_pv_port_init(void) >>>> +{ >>>> + IORange *pv_io_range = g_malloc(sizeof(IORange)); >>>> + >>>> + iorange_init(pv_io_range, &pv_io_range_ops, KVM_PV_PORT, 1); >>>> + ioport_register(pv_io_range); >>> >>> This modeling is still not ok. We don't open-code ports anymore, we >>> introduce devices. And this doesn't belong inro generic code as it is >> >> Do you mean introducing a new device instead of I/O port? > > I mean encapsulating the I/O registration (PIO or MMIO) in a QOM device A QOM device? Do you mean introduce a new device? If so, the guest should have a driver to know such device. Another problem is: we cannot use such device when the kernel is starting(the device's driver is not ready). If we use a new device, I think virtio-serial is enough. The reason why I do not use virtio-serial is: I want the feature can also work when the kernel is starting. Thanks Wen Congyang > and building that device only for target archs that supports it. Already > pointed you to examples in hw/kvm/. > > Jan >