kvm: notify host when the guest is panicked

If the target is x86/x86_64, the guest's kernel will write 0x01 to the port KVM_PV_EVENT_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 <[email protected]>

---
 hw/kvm/Makefile.objs |    2 +-
 hw/kvm/pv_event.c    |  109 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/kvm/pv_ioport.c   |   93 ++++++++++++++++++++++++++++++++++++++++++
 hw/pc_piix.c         |    9 ++++
 kvm.h                |    2 +
 5 files changed, 214 insertions(+), 1 deletions(-)
 create mode 100644 hw/kvm/pv_event.c
 create mode 100644 hw/kvm/pv_ioport.c

hw/kvm/Makefile.objs +1 -1

index 226497a..23e3b30 100644
@@ -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

hw/kvm/pv_event.c new file +20 -0

new file mode 100644
index 0000000..8897237
@@ -0,0 +1,109 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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>

hw/kvm/pv_event.c new file +22 -0

+    char *panicked_action;
+    int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
+    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+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(uint32_t panicked_action)
+{
+    switch (panicked_action) {
+    case PANICKED_REPORT:
+        panicked_mon_event("report");
+        break;

hw/kvm/pv_event.c new file +31 -0

+    case PANICKED_RESET:
+        panicked_mon_event("reset");
+        qemu_system_reset_request();
+        break;
+    }
+}
+
+static uint64_t supported_event(void)
+{
+    return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct pv_event_action *conf)
+{
+    if (event == KVM_PV_EVENT_PANICKED) {
+        panicked_perform_action(conf->panicked_action_value);
+    }
+}
+
+static int pv_event_init(struct pv_event_action *conf)
+{
+    if (!conf->panicked_action) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+        conf->panicked_action_value = PANICKED_PAUSE;
+    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+        conf->panicked_action_value = PANICKED_POWEROFF;
+    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+        conf->panicked_action_value = PANICKED_RESET;

hw/kvm/pv_event.c new file +6 -0

+
+#else
+void kvm_pv_event_init(void *opaque)
+{
+}
+#endif

hw/kvm/pv_ioport.c new file +39 -0

new file mode 100644
index 0000000..c2ed6b5
@@ -0,0 +1,93 @@
+/*
+ * QEMU KVM support, paravirtual I/O port device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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 "hw/isa.h"
+
+typedef struct {
+    ISADevice dev;
+    struct pv_event_action conf;
+    MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    return supported_event();
+}
+
+static void pv_io_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                        unsigned size)
+{
+    PVIOPortState *s = opaque;
+
+    handle_event(val, &s->conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+    .read = pv_io_read,
+    .write = pv_io_write,
+    .impl = {
+        .min_access_size = 4,

hw/kvm/pv_ioport.c new file +44 -0

+
+    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 1);
+    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
+
+    return 0;
+}
+
+static Property pv_ioport_properties[] = {
+    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pv_ioport_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+
+    ic->init = pv_ioport_initfn;
+    dc->no_user = 1;
+    dc->props = pv_ioport_properties;
+}
+
+static TypeInfo pv_ioport_info = {
+    .name          = PV_EVENT_DRIVER,
+    .parent        = TYPE_ISA_DEVICE,
+    .instance_size = sizeof(PVIOPortState),
+    .class_init    = pv_ioport_class_init,
+};
+
+static void pv_ioport_register_types(void)
+{
+    type_register_static(&pv_ioport_info);
+}
+
+type_init(pv_ioport_register_types)
+
+void kvm_pv_event_init(void *opaque)
+{
+    ISABus *bus = opaque;
+    ISADevice *dev;
+
+    dev = isa_create(bus, PV_EVENT_DRIVER);
+    qdev_init_nofail(&dev->qdev);
+}

hw/pc_piix.c +0 -0

index 0c0096f..4af8403 100644

hw/pc_piix.c +6 -0

 #define MAX_IDE_BUS 2
 

@@ -285,6 +288,12 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pc_pci_device_init(pci_bus);
     }
+
+#ifdef KVM_PV_EVENT_PORT
+    if (kvm_enabled()) {
+        kvm_pv_event_init(isa_bus);
+    }
+#endif
 }
 
 static void pc_init_pci(ram_addr_t ram_size,

kvm.h +2 -1

index 2617dd5..598dcbe 100644
@@ -222,4 +222,6 @@ int kvm_irqchip_add_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_remove_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_add_irq_notifier(KVMState *s, EventNotifier *n, int virq);
 int kvm_irqchip_remove_irq_notifier(KVMState *s, EventNotifier *n, int virq);
+
+void kvm_pv_event_init(void *opaque);
 #endif
--

1.7.1

Quoted 62 lines

If the target is x86/x86_64, the guest's kernel will write 0x01 to the port KVM_PV_EVENT_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 <[email protected]>

---
 hw/kvm/Makefile.objs |    2 +-
 hw/kvm/pv_event.c    |  109 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/kvm/pv_ioport.c   |   93 ++++++++++++++++++++++++++++++++++++++++++
 hw/pc_piix.c         |    9 ++++
 kvm.h                |    2 +
 5 files changed, 214 insertions(+), 1 deletions(-)
 create mode 100644 hw/kvm/pv_event.c
 create mode 100644 hw/kvm/pv_ioport.c

hw/kvm/Makefile.objs +1 -1

index 226497a..23e3b30 100644
@@ -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

hw/kvm/pv_event.c new file +20 -0

new file mode 100644
index 0000000..8897237
@@ -0,0 +1,109 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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>

hw/kvm/pv_event.c line 30

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+
+/* 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 */
+
+#define PV_EVENT_DRIVER     "kvm_pv_event"
+
+struct pv_event_action {

PVEventAction

Quoted 22 lines

hw/kvm/pv_event.c new file +22 -0

+    char *panicked_action;
+    int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
+    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+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(uint32_t panicked_action)
+{
+    switch (panicked_action) {
+    case PANICKED_REPORT:
+        panicked_mon_event("report");
+        break;

hw/kvm/pv_event.c line 62

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+
+    case PANICKED_PAUSE:
+        panicked_mon_event("pause");
+        vm_stop(RUN_STATE_GUEST_PANICKED);
+        break;
+
+    case PANICKED_POWEROFF:
+        panicked_mon_event("poweroff");
+        qemu_system_shutdown_request();
+        break;

Misses a line break unlike other cases.

Quoted 31 lines

hw/kvm/pv_event.c new file +31 -0

+    case PANICKED_RESET:
+        panicked_mon_event("reset");
+        qemu_system_reset_request();
+        break;
+    }
+}
+
+static uint64_t supported_event(void)
+{
+    return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct pv_event_action *conf)
+{
+    if (event == KVM_PV_EVENT_PANICKED) {
+        panicked_perform_action(conf->panicked_action_value);
+    }
+}
+
+static int pv_event_init(struct pv_event_action *conf)
+{
+    if (!conf->panicked_action) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+        conf->panicked_action_value = PANICKED_PAUSE;
+    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+        conf->panicked_action_value = PANICKED_POWEROFF;
+    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+        conf->panicked_action_value = PANICKED_RESET;

hw/kvm/pv_event.c line 103

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+    } else {
+        return -1;
+    }
+
+    return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "pv_ioport.c"

I'd rather not include any .c files but insert the contents here directly.

Quoted 51 lines

hw/kvm/pv_event.c new file +6 -0

+
+#else
+void kvm_pv_event_init(void *opaque)
+{
+}
+#endif

hw/kvm/pv_ioport.c new file +39 -0

new file mode 100644
index 0000000..c2ed6b5
@@ -0,0 +1,93 @@
+/*
+ * QEMU KVM support, paravirtual I/O port device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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 "hw/isa.h"
+
+typedef struct {
+    ISADevice dev;
+    struct pv_event_action conf;
+    MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    return supported_event();
+}
+
+static void pv_io_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                        unsigned size)
+{
+    PVIOPortState *s = opaque;
+
+    handle_event(val, &s->conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+    .read = pv_io_read,
+    .write = pv_io_write,
+    .impl = {
+        .min_access_size = 4,

hw/kvm/pv_ioport.c line 49

Quoted 10 lines

hw/kvm/pv_ioport.c new file +10 -0

+        .max_access_size = 4,
+    },
+};
+
+static int pv_ioport_initfn(ISADevice *dev)
+{
+    PVIOPortState *s = DO_UPCAST(PVIOPortState, dev, dev);
+
+    if (pv_event_init(&s->conf) < 0)
+        return -1;

Mandatory braces missing.

Quoted 50 lines

hw/kvm/pv_ioport.c new file +44 -0

+
+    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 1);
+    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
+
+    return 0;
+}
+
+static Property pv_ioport_properties[] = {
+    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pv_ioport_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+
+    ic->init = pv_ioport_initfn;
+    dc->no_user = 1;
+    dc->props = pv_ioport_properties;
+}
+
+static TypeInfo pv_ioport_info = {
+    .name          = PV_EVENT_DRIVER,
+    .parent        = TYPE_ISA_DEVICE,
+    .instance_size = sizeof(PVIOPortState),
+    .class_init    = pv_ioport_class_init,
+};
+
+static void pv_ioport_register_types(void)
+{
+    type_register_static(&pv_ioport_info);
+}
+
+type_init(pv_ioport_register_types)
+
+void kvm_pv_event_init(void *opaque)
+{
+    ISABus *bus = opaque;
+    ISADevice *dev;
+
+    dev = isa_create(bus, PV_EVENT_DRIVER);
+    qdev_init_nofail(&dev->qdev);
+}

hw/pc_piix.c +0 -0

index 0c0096f..4af8403 100644
@@ -46,6 +46,9 @@
 #ifdef CONFIG_XEN

hw/pc_piix.c line 51

Quoted 5 lines

hw/pc_piix.c +3 -0

 #  include <xen/hvm/hvm_info_table.h>
 #endif
+#ifdef CONFIG_KVM
+#   include <asm/kvm_para.h>
+#endif

I'd remove this and the #ifdeffery below since a stub function is provided. This is not performance critical.

Quoted 32 lines

hw/pc_piix.c +6 -0

 #define MAX_IDE_BUS 2
 

@@ -285,6 +288,12 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pc_pci_device_init(pci_bus);
     }
+
+#ifdef KVM_PV_EVENT_PORT
+    if (kvm_enabled()) {
+        kvm_pv_event_init(isa_bus);
+    }
+#endif
 }
 
 static void pc_init_pci(ram_addr_t ram_size,

kvm.h +2 -1

index 2617dd5..598dcbe 100644
@@ -222,4 +222,6 @@ int kvm_irqchip_add_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_remove_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_add_irq_notifier(KVMState *s, EventNotifier *n, int virq);
 int kvm_irqchip_remove_irq_notifier(KVMState *s, EventNotifier *n, int virq);
+
+void kvm_pv_event_init(void *opaque);
 #endif
--

1.7.1

At 08/09/2012 03:01 AM, Blue Swirl Wrote:

Quoted 269 lines · Wen Congyang

Quoted 62 lines

If the target is x86/x86_64, the guest's kernel will write 0x01 to the port KVM_PV_EVENT_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 <[email protected]>

---
 hw/kvm/Makefile.objs |    2 +-
 hw/kvm/pv_event.c    |  109 ++++++++++++++++++++++++++++++++++++++++++++++++++
 hw/kvm/pv_ioport.c   |   93 ++++++++++++++++++++++++++++++++++++++++++
 hw/pc_piix.c         |    9 ++++
 kvm.h                |    2 +
 5 files changed, 214 insertions(+), 1 deletions(-)
 create mode 100644 hw/kvm/pv_event.c
 create mode 100644 hw/kvm/pv_ioport.c

hw/kvm/Makefile.objs +1 -1

index 226497a..23e3b30 100644
@@ -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

hw/kvm/pv_event.c new file +20 -0

new file mode 100644
index 0000000..8897237
@@ -0,0 +1,109 @@
+/*
+ * QEMU KVM support, paravirtual event device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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>

hw/kvm/pv_event.c line 30

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+
+/* 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 */
+
+#define PV_EVENT_DRIVER     "kvm_pv_event"
+
+struct pv_event_action {

PVEventAction

Quoted 22 lines

hw/kvm/pv_event.c new file +22 -0

+    char *panicked_action;
+    int panicked_action_value;
+};
+
+#define DEFINE_PV_EVENT_PROPERTIES(_state, _conf)   \
+    DEFINE_PROP_STRING("panicked_action", _state, _conf.panicked_action)
+
+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(uint32_t panicked_action)
+{
+    switch (panicked_action) {
+    case PANICKED_REPORT:
+        panicked_mon_event("report");
+        break;

hw/kvm/pv_event.c line 62

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+
+    case PANICKED_PAUSE:
+        panicked_mon_event("pause");
+        vm_stop(RUN_STATE_GUEST_PANICKED);
+        break;
+
+    case PANICKED_POWEROFF:
+        panicked_mon_event("poweroff");
+        qemu_system_shutdown_request();
+        break;

Misses a line break unlike other cases.

Quoted 31 lines

hw/kvm/pv_event.c new file +31 -0

+    case PANICKED_RESET:
+        panicked_mon_event("reset");
+        qemu_system_reset_request();
+        break;
+    }
+}
+
+static uint64_t supported_event(void)
+{
+    return 1 << KVM_PV_FEATURE_PANICKED;
+}
+
+static void handle_event(int event, struct pv_event_action *conf)
+{
+    if (event == KVM_PV_EVENT_PANICKED) {
+        panicked_perform_action(conf->panicked_action_value);
+    }
+}
+
+static int pv_event_init(struct pv_event_action *conf)
+{
+    if (!conf->panicked_action) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "none") == 0) {
+        conf->panicked_action_value = PANICKED_REPORT;
+    } else if (strcasecmp(conf->panicked_action, "pause") == 0) {
+        conf->panicked_action_value = PANICKED_PAUSE;
+    } else if (strcasecmp(conf->panicked_action, "poweroff") == 0) {
+        conf->panicked_action_value = PANICKED_POWEROFF;
+    } else if (strcasecmp(conf->panicked_action, "reset") == 0) {
+        conf->panicked_action_value = PANICKED_RESET;

hw/kvm/pv_event.c line 103

Quoted 10 lines

hw/kvm/pv_event.c new file +10 -0

+    } else {
+        return -1;
+    }
+
+    return 0;
+}
+
+#if defined(KVM_PV_EVENT_PORT)
+
+#include "pv_ioport.c"

I'd rather not include any .c files but insert the contents here directly.

Quoted 51 lines

hw/kvm/pv_event.c new file +6 -0

+
+#else
+void kvm_pv_event_init(void *opaque)
+{
+}
+#endif

hw/kvm/pv_ioport.c new file +39 -0

new file mode 100644
index 0000000..c2ed6b5
@@ -0,0 +1,93 @@
+/*
+ * QEMU KVM support, paravirtual I/O port device
+ *
+ * Copyright Fujitsu, Corp. 2012
+ *
+ * Authors:
+ *     Wen Congyang <[email protected]>
+ *
+ * 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 "hw/isa.h"
+
+typedef struct {
+    ISADevice dev;
+    struct pv_event_action conf;
+    MemoryRegion ioport;
+} PVIOPortState;
+
+static uint64_t pv_io_read(void *opaque, target_phys_addr_t addr, unsigned size)
+{
+    return supported_event();
+}
+
+static void pv_io_write(void *opaque, target_phys_addr_t addr, uint64_t val,
+                        unsigned size)
+{
+    PVIOPortState *s = opaque;
+
+    handle_event(val, &s->conf);
+}
+
+static const MemoryRegionOps pv_io_ops = {
+    .read = pv_io_read,
+    .write = pv_io_write,
+    .impl = {
+        .min_access_size = 4,

hw/kvm/pv_ioport.c line 49

Quoted 10 lines

hw/kvm/pv_ioport.c new file +10 -0

+        .max_access_size = 4,
+    },
+};
+
+static int pv_ioport_initfn(ISADevice *dev)
+{
+    PVIOPortState *s = DO_UPCAST(PVIOPortState, dev, dev);
+
+    if (pv_event_init(&s->conf) < 0)
+        return -1;

Mandatory braces missing.

Quoted 50 lines

hw/kvm/pv_ioport.c new file +44 -0

+
+    memory_region_init_io(&s->ioport, &pv_io_ops, s, "pv_event", 1);
+    isa_register_ioport(dev, &s->ioport, KVM_PV_EVENT_PORT);
+
+    return 0;
+}
+
+static Property pv_ioport_properties[] = {
+    DEFINE_PV_EVENT_PROPERTIES(PVIOPortState, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pv_ioport_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    ISADeviceClass *ic = ISA_DEVICE_CLASS(klass);
+
+    ic->init = pv_ioport_initfn;
+    dc->no_user = 1;
+    dc->props = pv_ioport_properties;
+}
+
+static TypeInfo pv_ioport_info = {
+    .name          = PV_EVENT_DRIVER,
+    .parent        = TYPE_ISA_DEVICE,
+    .instance_size = sizeof(PVIOPortState),
+    .class_init    = pv_ioport_class_init,
+};
+
+static void pv_ioport_register_types(void)
+{
+    type_register_static(&pv_ioport_info);
+}
+
+type_init(pv_ioport_register_types)
+
+void kvm_pv_event_init(void *opaque)
+{
+    ISABus *bus = opaque;
+    ISADevice *dev;
+
+    dev = isa_create(bus, PV_EVENT_DRIVER);
+    qdev_init_nofail(&dev->qdev);
+}

hw/pc_piix.c +0 -0

index 0c0096f..4af8403 100644
@@ -46,6 +46,9 @@
 #ifdef CONFIG_XEN

Quoted 8 lines

hw/pc_piix.c line 51

Quoted 5 lines

hw/pc_piix.c +3 -0

 #  include <xen/hvm/hvm_info_table.h>
 #endif
+#ifdef CONFIG_KVM
+#   include <asm/kvm_para.h>
+#endif

I'd remove this and the #ifdeffery below since a stub function is provided. This is not performance critical.

The stub function is in the file hw/kvm/pv_event.c, and this file will be complied only when CONFIG_KVM is y.

Thanks
Wen Congyang

Quoted 33 lines

Quoted 32 lines

hw/pc_piix.c +6 -0

 #define MAX_IDE_BUS 2
 

@@ -285,6 +288,12 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled) {
         pc_pci_device_init(pci_bus);
     }
+
+#ifdef KVM_PV_EVENT_PORT
+    if (kvm_enabled()) {
+        kvm_pv_event_init(isa_bus);
+    }
+#endif
 }
 
 static void pc_init_pci(ram_addr_t ram_size,

kvm.h +2 -1

index 2617dd5..598dcbe 100644
@@ -222,4 +222,6 @@ int kvm_irqchip_add_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_remove_irqfd(KVMState *s, int fd, int virq);
 int kvm_irqchip_add_irq_notifier(KVMState *s, EventNotifier *n, int virq);
 int kvm_irqchip_remove_irq_notifier(KVMState *s, EventNotifier *n, int virq);
+
+void kvm_pv_event_init(void *opaque);
 #endif
--

1.7.1

Documentation/virtual/kvm/pv_event.txt new file +3 -0

new file mode 100644
index 0000000..0ebc890
@@ -0,0 +1,32 @@
+The KVM paravirtual event interface
+=================================
+

Quoted 13 lines

Documentation/virtual/kvm/pv_event.txt new file +7 -0

new file mode 100644
index 0000000..0ebc890
@@ -0,0 +1,32 @@
+The KVM paravirtual event interface
+=================================
+
+Initializing the paravirtual event interface
+======================
+kvm_pv_event_init()
+Argiments:

Documentation/virtual/kvm/pv_event.txt line 13

Quoted 6 lines

Documentation/virtual/kvm/pv_event.txt new file +6 -0

+	None
+
+Return Value:
+	0 : The guest kernel can't use paravirtual event interface.
+	-1: The guest kernel can use paravirtual event interface.
+

This documentation has the can and can't backwards.

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Signed-off-by Wen Congyang <[email protected]>

---
 Documentation/virtual/kvm/pv_event.txt |   32 ++++++++++++++++++++++++++++++++
 arch/ia64/include/asm/kvm_para.h       |   14 ++++++++++++++
 arch/powerpc/include/asm/kvm_para.h    |   14 ++++++++++++++
 arch/s390/include/asm/kvm_para.h       |   14 ++++++++++++++
 arch/x86/include/asm/kvm_para.h        |   27 +++++++++++++++++++++++++++
 arch/x86/kernel/kvm.c                  |   25 +++++++++++++++++++++++++
 include/linux/kvm_para.h               |   23 +++++++++++++++++++++++
 7 files changed, 149 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/virtual/kvm/pv_event.txt

Documentation/virtual/kvm/pv_event.txt new file +32 -0

new file mode 100644
index 0000000..0ebc890
@@ -0,0 +1,32 @@
+The KVM paravirtual event interface
+=================================
+
+Initializing the paravirtual event interface
+======================
+kvm_pv_event_init()
+Argiments:
+	None
+
+Return Value:
+	0 : The guest kernel can't use paravirtual event interface.
+	-1: The guest kernel can use paravirtual event interface.
+
+Querying whether the event can be ejected
+======================
+kvm_pv_has_feature()
+Arguments:
+	feature: The bit value of this paravirtual event to query
+
+Return Value:
+	0: The guest kernel can't eject this paravirtual event.
+	1: The guest kernel can eject this paravirtual event.
+
+
+Ejecting paravirtual event
+======================
+kvm_pv_eject_event()
+Arguments:
+	event: The event to be ejected.
+
+Return Value:
+	None

arch/ia64/include/asm/kvm_para.h +14 -0

index 2019cb9..b5ec658 100644
@@ -31,6 +31,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif
 
 #endif

arch/powerpc/include/asm/kvm_para.h +14 -0

index c18916b..01b98c7 100644
@@ -211,6 +211,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* __POWERPC_KVM_PARA_H__ */

arch/s390/include/asm/kvm_para.h +14 -0

index da44867..00ce058 100644
@@ -154,6 +154,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif
 
 #endif /* __S390_KVM_PARA_H */

arch/x86/include/asm/kvm_para.h +27 -0

index 2f7712e..7d297f0 100644
@@ -96,8 +96,11 @@ struct kvm_vcpu_pv_apf_data {
 #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
 #define KVM_PV_EOI_DISABLED 0x0
 
+#define KVM_PV_EVENT_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>
+#include <linux/ioport.h>
 
 extern void kvmclock_init(void);
 extern int kvm_register_clock(char *txt);

@@ -228,6 +231,30 @@ static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
+		return -1;
+
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	unsigned int features = inl(KVM_PV_EVENT_PORT);
+
+	/* Reading from an invalid I/O port will return -1 */
+	if (features == ~0)
+		features = 0;
+
+	return features;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+	outl(event, KVM_PV_EVENT_PORT);
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_KVM_PARA_H */

arch/x86/kernel/kvm.c +25 -0

index c1d61ee..6129459 100644
@@ -368,6 +368,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
 	.notifier_call = kvm_pv_reboot_notify,
 };
 
+static int
+kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
+{
+	kvm_pv_eject_event(KVM_PV_EVENT_PANICKED);
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block kvm_pv_panic_nb = {
+	.notifier_call = kvm_pv_panic_notify,
+};
+
 static u64 kvm_steal_clock(int cpu)
 {
 	u64 steal;

@@ -447,6 +458,20 @@ static void __init kvm_apf_trap_init(void)
 	set_intr_gate(14, &async_page_fault);
 }
 
+static void __init kvm_pv_panicked_event_init(void)
+{
+	if (!kvm_para_available())
+		return;
+
+	if (kvm_pv_event_init())
+		return;
+
+	if (kvm_pv_has_feature(KVM_PV_FEATURE_PANICKED))
+		atomic_notifier_chain_register(&panic_notifier_list,
+			&kvm_pv_panic_nb);
+}
+arch_initcall(kvm_pv_panicked_event_init);
+
 void __init kvm_guest_init(void)
 {
 	int i;

include/linux/kvm_para.h +23 -0

index ff476dd..8e0fb81 100644
@@ -20,6 +20,12 @@
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
 
+/* The bit of supported pv event */
+#define KVM_PV_FEATURE_PANICKED	0
+
+/* The pv event value */
+#define KVM_PV_EVENT_PANICKED	1
+
 /*
  * hypercalls use architecture specific
  */

@@ -33,5 +39,22 @@ static inline int kvm_para_has_feature(unsigned int feature)
 		return 1;
 	return 0;
 }
+
+static inline int kvm_pv_event_init(void)
+{
+	return kvm_arch_pv_event_init();
+}
+
+static inline int kvm_pv_has_feature(unsigned int feature)
+{
+	if (kvm_arch_pv_features() & (1UL << feature))
+		return 1;
+	return 0;
+}
+
+static inline void kvm_pv_eject_event(unsigned int event)
+{
+	kvm_arch_pv_eject_event(event);
+}
 #endif /* __KERNEL__ */
 #endif /* __LINUX_KVM_PARA_H */

Signature · 6 lines

1.7.1

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

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.

- It works as early as serial console output does (panics before that should be rare).
- It allows you to see why the guest panicked.

Quoted 24 lines · Marcelo Tosatti

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 3 lines

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.

But it _does_ depend on a serial console,

and furthermore requires
libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency).

Quoted 3 lines

- It works as early as serial console output does (panics before that should be rare).
- It allows you to see why the guest panicked.

I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable.

Quoted 25 lines · Eric Blake

Quoted 24 lines · Marcelo Tosatti

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 5 lines

Quoted 3 lines

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.

But it _does_ depend on a serial console,

Which already exists and is supported.

Quoted 10 lines

and furthermore requires
libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency).

Quoted 3 lines

- It works as early as serial console output does (panics before that should be rare).
- It allows you to see why the guest panicked.

Quoted 3 lines

I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable.

Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely?

Quoted 48 lines · Marcelo Tosatti

Quoted 25 lines · Eric Blake

Quoted 24 lines · Marcelo Tosatti

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 5 lines

Quoted 3 lines

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.

But it _does_ depend on a serial console,

Which already exists and is supported.

Quoted 13 lines

and furthermore requires
libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency).

Quoted 3 lines

- It works as early as serial console output does (panics before that should be rare).
- It allows you to see why the guest panicked.

I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable.

Quoted 3 lines

Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely?

It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with "Kernel panic - not syncing" in it.

Quoted 52 lines · Gleb Natapov

Quoted 51 lines · Marcelo Tosatti

Quoted 25 lines · Eric Blake

Quoted 24 lines · Marcelo Tosatti

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 5 lines

Quoted 3 lines

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.

But it _does_ depend on a serial console,

Which already exists and is supported.

Quoted 6 lines

and furthermore requires
libvirt to tee the serial console (right now, libvirt can treat the console as an opaque pass-through to the end user, but if you expect libvirt to parse the serial console for a particular string, you've lost some efficiency).

Quoted 7 lines

Quoted 3 lines

- It works as early as serial console output does (panics before that should be rare).
- It allows you to see why the guest panicked.

I think your arguments for a serial console have already been made and refuted in earlier versions of this patch series, which is WHY this series is still applicable.

Refuted why, exactly? Efficiency to parse serial console output in libvirt should not be a major issue surely?

Quoted 4 lines

It is not zero config (guests do not send console output to serial by default). If vm users want to use serial for its working console panic notification will trigger every time user examines dmesg with "Kernel panic - not syncing" in it.

Ok, then it would have to be a dedicated serial console which starts to become funny.

Use a simple virtio device, then, it starts early enough (or can be made to) during kernel init for most relevant production panics, and works for all architectures.

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 26 lines · Jan Kiszka

Quoted 25 lines · Daniel P. Berrange

Quoted 23 lines · Marcelo Tosatti

Quoted 13 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

Quoted 5 lines

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

Quoted 4 lines

Quoted 3 lines

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Yan.

Quoted 13 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Quoted 14 lines

Quoted 14 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 45 lines · Marcelo Tosatti

Quoted 33 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Quoted 5 lines

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Quoted 1 line

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Forget about !x86 platforms. They have their own way to do this sort of thing.

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Regards,

Anthony Liguori

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

Can this new infrastructure be used by other architectures?

Do you consider allowing support for Windows as overengineering?

Quoted 19 lines

Regards,

Anthony Liguori

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 54 lines · Marcelo Tosatti

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 8 lines

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

Not sure the semantics of blink but that might be a good place for a pvops hook.

Quoted 9 lines

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Quoted 6 lines

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO.

Quoted 1 line

Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU.

From the patch description:

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Regards,

Anthony Liguori

Quoted 12 lines

Quoted 12 lines

Regards,

Anthony Liguori

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Quoted 88 lines · Anthony Liguori

Quoted 54 lines · Marcelo Tosatti

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 8 lines

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

Not sure the semantics of blink but that might be a good place for a pvops hook.

Quoted 9 lines

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Quoted 6 lines

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO.

Quoted 5 lines

Quoted 1 line

Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU.

From the patch description:

"Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked."

Wen, auto dump means dump of guest memory?

In that case, the notification should obviously stop the guest otherwise the guest might be reset by the time memdump from QEMU monitor runs.

But kexec supports dumping of memory already (i suppose it can do automatic dump+{reboot,shutdown}).

Quoted 4 lines

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Unsure about hooking at BSOD time. But Windows has configurable memory dump/reset/reboot, so yes it should not necessary.

Quoted 29 lines

Regards,

Anthony Liguori

Quoted 12 lines

Quoted 12 lines

Regards,

Anthony Liguori

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Quoted 95 lines · Marcelo Tosatti

Quoted 93 lines · Anthony Liguori

Quoted 54 lines · Marcelo Tosatti

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 8 lines

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

Not sure the semantics of blink but that might be a good place for a pvops hook.

Quoted 9 lines

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Quoted 6 lines

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO.

Quoted 1 line

Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU.

Quoted 6 lines

From the patch description:

"Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked."

Why does this mandated another runstate?

QEMU can simply mark the VCPUs as stopped and raise a QMP event.

The kernel doesn't care if the VCPUs
are stopped or panicked.

Quoted 11 lines

Wen, auto dump means dump of guest memory?

In that case, the notification should obviously stop the guest otherwise the guest might be reset by the time memdump from QEMU monitor runs.

But kexec supports dumping of memory already (i suppose it can do automatic dump+{reboot,shutdown}).

Quoted 2 lines

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

Quoted 5 lines

Quoted 2 lines

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Unsure about hooking at BSOD time. But Windows has configurable memory dump/reset/reboot, so yes it should not necessary.

Do you mean it's not necessary to hook BSOD?

I've very often gotten asked: We know 1 person is experiencing this crash condition, can we figure out from the host how many other VMs are experiencing this crash too instead of waiting for a user to complain?

That's the primary use-case for this notification IMHO. Just a simple status LED from the guest to indicate that it's in a bad state.

Regards,

Anthony Liguori

Quoted 29 lines

Quoted 29 lines

Regards,

Anthony Liguori

Quoted 12 lines

Quoted 12 lines

Regards,

Anthony Liguori

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Quoted 93 lines

Quoted 54 lines · Marcelo Tosatti

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 8 lines

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

Not sure the semantics of blink but that might be a good place for a pvops hook.

Quoted 9 lines

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Quoted 6 lines

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO.

Quoted 1 line

Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU.

Quoted 1 line

From the patch description:

"Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked."

Wen, auto dump means dump of guest memory?

In that case, the notification should obviously stop the guest otherwise the guest might be reset by the time memdump from QEMU monitor runs.

But kexec supports dumping of memory already (i suppose it can do automatic dump+{reboot,shutdown}).

Quoted 5 lines

Quoted 2 lines

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Unsure about hooking at BSOD time. But Windows has configurable memory dump/reset/reboot, so yes it should not necessary.

Quoted 24 lines

Regards,

Anthony Liguori

Quoted 12 lines

Quoted 12 lines

Regards,

Anthony Liguori

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 4 lines

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Quoted 5 lines · Anthony Liguori

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Yan says in other email that is is possible to register a bugcheck callback.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 54 lines · Marcelo Tosatti

Quoted 53 lines · Anthony Liguori

Quoted 38 lines · Marcelo Tosatti

Quoted 37 lines · Yan Vugenfirer

Quoted 22 lines · Jan Kiszka

Quoted 21 lines · Daniel P. Berrange

Quoted 20 lines · Marcelo Tosatti

Quoted 18 lines · Wen Congyang

We can know the guest is panicked when the guest runs on xen. But we do not have such feature on kvm.

Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.

We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.

We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

How about searching for the "Kernel panic - not syncing" string in the guests serial output? Say libvirtd could take an action upon that?

No, this is not satisfactory. It depends on the guest OS being configured to use the serial port for console output which we cannot mandate, since it may well be required for other purposes.

Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Quoted 8 lines

Quoted 1 line

Yan.

Considering whether a "panic-device" should cover other OSes is also \

something to consider. Even for Linux, is "panic" the only case which should be reported via the mechanism? What about oopses without panic?

Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Quoted 8 lines

Quoted 2 lines

Forget about !x86 platforms. They have their own way to do this sort of thing.

The panic function in kernel/panic.c has the following options, which appear to be arch independent, on panic:

- reboot
- blink

Not sure the semantics of blink but that might be a good place for a pvops hook.

Quoted 9 lines

None are paravirtual interfaces however.

Quoted 5 lines

Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.

Quoted 6 lines

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO.

Quoted 1 line

Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU.

Quoted 1 line

Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no?

Regards,

Anthony Liguori

Quoted 12 lines

Quoted 12 lines

Regards,

Anthony Liguori

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Well, we have more than a single serial port, even when leaving virtio-serial aside...

Jan

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Signature · 6 lines

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Forget about !x86 platforms. They have their own way to do this sort of thing. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this.