* Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter [not found] ` <4FEC153B.6040300@siemens.com> @ 2012-07-03 6:07 ` Wen Congyang 2012-07-03 6:36 ` Jan Kiszka 0 siblings, 1 reply; 4+ messages in thread From: Wen Congyang @ 2012-07-03 6:07 UTC (permalink / raw) 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 <wency@cn.fujitsu.com> >>>> --- >>>> 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 <stdarg.h> >>>> >>>> #include <linux/kvm.h> >>>> +#include <linux/kvm_para.h> >>>> +#include <asm/kvm_para.h> >>>> >>>> #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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter 2012-07-03 6:07 ` [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter Wen Congyang @ 2012-07-03 6:36 ` Jan Kiszka 2012-07-03 6:43 ` Wen Congyang 0 siblings, 1 reply; 4+ messages in thread From: Jan Kiszka @ 2012-07-03 6:36 UTC (permalink / raw) To: Wen Congyang Cc: Gleb Natapov, kvm list, qemu-devel, linux-kernel@vger.kernel.org, Avi Kivity, KAMEZAWA Hiroyuki On 2012-07-03 08:07, Wen Congyang wrote: > 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 <wency@cn.fujitsu.com> >>>>> --- >>>>> 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 <stdarg.h> >>>>> >>>>> #include <linux/kvm.h> >>>>> +#include <linux/kvm_para.h> >>>>> +#include <asm/kvm_para.h> >>>>> >>>>> #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. I'm not talking about changing the interface to the guest, I'm talking about how to model it in QEMU. And that difference would be transparent to the guest. I pointed you to examples like hw/kvm/clock.c. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter 2012-07-03 6:36 ` Jan Kiszka @ 2012-07-03 6:43 ` Wen Congyang 2012-07-03 6:45 ` Jan Kiszka 0 siblings, 1 reply; 4+ messages in thread From: Wen Congyang @ 2012-07-03 6:43 UTC (permalink / raw) To: Jan Kiszka Cc: Gleb Natapov, kvm list, qemu-devel, linux-kernel@vger.kernel.org, Avi Kivity, KAMEZAWA Hiroyuki At 07/03/2012 02:36 PM, Jan Kiszka Wrote: > On 2012-07-03 08:07, Wen Congyang wrote: >> 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 <wency@cn.fujitsu.com> >>>>>> --- >>>>>> 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 <stdarg.h> >>>>>> >>>>>> #include <linux/kvm.h> >>>>>> +#include <linux/kvm_para.h> >>>>>> +#include <asm/kvm_para.h> >>>>>> >>>>>> #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. > > I'm not talking about changing the interface to the guest, I'm talking > about how to model it in QEMU. And that difference would be transparent > to the guest. I pointed you to examples like hw/kvm/clock.c. OK, I will read the code in hw/kvm/clock.c Thanks for your help. Wen Congyang > > Jan > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter 2012-07-03 6:43 ` Wen Congyang @ 2012-07-03 6:45 ` Jan Kiszka 0 siblings, 0 replies; 4+ messages in thread From: Jan Kiszka @ 2012-07-03 6:45 UTC (permalink / raw) To: Wen Congyang Cc: Gleb Natapov, kvm list, qemu-devel, linux-kernel@vger.kernel.org, Avi Kivity, KAMEZAWA Hiroyuki On 2012-07-03 08:43, Wen Congyang wrote: >> I'm not talking about changing the interface to the guest, I'm talking >> about how to model it in QEMU. And that difference would be transparent >> to the guest. I pointed you to examples like hw/kvm/clock.c. > > OK, I will read the code in hw/kvm/clock.c Just to avoid confusion: That example is just good for a trivial framework. It does vmstate saving, something you don't need as your "device" is stateless. If you want to find out how to register PIO ranges, also check e.g. hw/pcspk.c. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-07-03 6:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4FEAAE6E.7070302@cn.fujitsu.com>
[not found] ` <4FEAAFFF.40401@cn.fujitsu.com>
[not found] ` <4FEB1B06.4050309@siemens.com>
[not found] ` <4FEBB044.1000306@cn.fujitsu.com>
[not found] ` <4FEC153B.6040300@siemens.com>
2012-07-03 6:07 ` [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter Wen Congyang
2012-07-03 6:36 ` Jan Kiszka
2012-07-03 6:43 ` Wen Congyang
2012-07-03 6:45 ` Jan Kiszka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).