Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-07-03 Thread Wen Congyang 
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 we...@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
 

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-07-03 Thread Jan Kiszka 
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 we...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-07-03 Thread Wen Congyang 
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 we...@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
 

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-07-03 Thread Jan Kiszka 
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


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-28 Thread Jan Kiszka 
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 we...@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
and building that device only for target archs that supports it. Already
pointed you to examples in hw/kvm/.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-27 Thread Wen Congyang 
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 we...@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);
+}
+#else
+void kvm_pv_port_init(void)
+{
+}
+#endif
+
+int select_panicked_action(const char *p)
+{
+if (strcasecmp(p, none) == 0) {
+panicked_action = PANICKED_REPORT;
+} else if (strcasecmp(p, pause) == 0) {
+panicked_action = PANICKED_PAUSE;
+} else if (strcasecmp(p, poweroff) == 0) {
+panicked_action = PANICKED_POWEROFF;
+} else if (strcasecmp(p, reset) == 0) {
+panicked_action = PANICKED_RESET;
+} else {
+return -1;
+}
+
+return 0;
+}
diff --git a/kvm-stub.c b/kvm-stub.c
index ec9a364..318e967 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -151,3 +151,12 @@ int kvm_irqchip_remove_irqfd(KVMState *s, int fd, int virq)
 {
 return -ENOSYS;
 }
+
+void kvm_pv_port_init(void)
+{
+}
+
+int select_panicked_action(const char *p)
+{
+return -1;
+}
diff --git a/kvm.h b/kvm.h
index 9c7b0ea..d174d5a 100644
--- a/kvm.h
+++ b/kvm.h
@@ -64,6 +64,9 @@ int kvm_has_gsi_routing(void);
 
 int kvm_allows_irq0_override(void);
 
+void kvm_pv_port_init(void);
+int select_panicked_action(const char *p);
+
 #ifdef NEED_CPU_H
 int kvm_init_vcpu(CPUArchState *env);
 
diff --git a/qemu-options.hx b/qemu-options.hx
index 8b66264..4a061bf 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2743,6 +2743,21 @@ DEF(qtest-log, HAS_ARG, QEMU_OPTION_qtest_log,
 -qtest-log LOG  specify tracing options\n,
 QEMU_ARCH_ALL)
 
+DEF(onpanic, HAS_ARG, QEMU_OPTION_onpanic, \
+-onpanic none|pause|poweroff|reset\n \
+action when the

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-27 Thread Jan Kiszka 
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 we...@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
x86-only. Will avoid that #ifdef as well.

Thanks
Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-27 Thread Cornelia Huck 
On Wed, 27 Jun 2012 15:02:23 +0800
Wen Congyang we...@cn.fujitsu.com 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

Would it be useful to add some dump the guest actions here?

 
 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 we...@cn.fujitsu.com

 +static void kvm_pv_port_read(IORange *iorange, uint64_t offset, unsigned 
 width,
 + uint64_t *data)
 +{
 +*data = (1  KVM_PV_FEATURE_PANICKED);
 +}

 +
 +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);
 +}
 +#else
 +void kvm_pv_port_init(void)
 +{
 +}
 +#endif

 @@ -3641,6 +3647,10 @@ int main(int argc, char **argv, char **envp)
  }
  }
 
 +if (kvm_enabled()) {
 +kvm_pv_port_init();
 +}
 +
  if (incoming) {
  Error *errp = NULL;
  int ret = qemu_start_incoming_migration(incoming, errp);

I/O ports won't work for s390, yet we'll likely want panic
notifications there as well. This will need some more abstraction.

Cornelia

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-27 Thread Daniel P. Berrange 
On Wed, Jun 27, 2012 at 04:52:32PM +0200, Cornelia Huck wrote:
 On Wed, 27 Jun 2012 15:02:23 +0800
 Wen Congyang we...@cn.fujitsu.com 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
 
 Would it be useful to add some dump the guest actions here?

Better off leaving that to the mgmt layer using QEMU. If you
tried to directly handle dump the guest in the context of
the panic notifier then you add all sorts of extra complexity
to this otherwise simple feature. For a start the you need to
tell it what filename to use, which is not something you can
necessarily decide at the time QEMU starts - you might want
a separate filename each time a panic ocurrs. THe mgmt app
might not even want QEMU to dump to a file - it might want
to use a socket, or pass in a file descriptor at time of
dump. All in all, it is better to keep the panic notifier
simple, and let the mgmt app then decide whether to take
a dump separately, using existing QEMU monitor commands
and features.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6 v5] deal with guest panicked event accoring to -onpanic parameter

2012-06-27 Thread Wen Congyang 
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 we...@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?

Thanks
Wen Congyang

 x86-only. Will avoid that #ifdef as well.
 
 Thanks
 Jan
 

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html