[Qemu-devel] [PATCH v7 0/4] cpus: Add generic "nmi" monitor command support

[Qemu-devel] [PATCH v7 0/4] cpus: Add generic "nmi" monitor command support

[Alexey Kardashevskiy]

This adds an "nmi" monitor command handler per CPUs.
x86, s390 and ppc CPUS are supported.

Please comment. Thanks.

Changes:
v7:
* fixed typenames, function names, copyrights
* s390x QOM'ed for later addition of the NMI interface
* Since none of x86 machines is QOM'ed, postpone migration to new interface for x86

v6:
* back 5 steps and make it an interface again

v5:
* added Error** to the callback
* fixed some comments

v4:
* now it is not nmi() but nmi_monitor_handler() to avoid confusion

v3:
* patches reorganized
* comments from v2 addressed, more details are in individual commit logs

v2:
* moved from machine interface to CPUClass callback
* s390 and x86 moved to target-s390/target-i386
* x86 handler delivers to the current CPU only now




Alexey Kardashevskiy (4):
  cpus: Define callback for QEMU "nmi" command
  s390x: Convert QEMUMachine to MachineClass
  s390x: Migrate to new NMI interface
  spapr: Add support for new NMI interface

 cpus.c                     | 17 ++--------
 hmp-commands.hx            |  6 ++--
 hw/core/Makefile.objs      |  1 +
 hw/core/nmi.c              | 84 ++++++++++++++++++++++++++++++++++++++++++++++
 hw/ppc/spapr.c             | 21 ++++++++++++
 hw/s390x/s390-virtio-ccw.c | 49 ++++++++++++++++++---------
 hw/s390x/s390-virtio.c     | 59 ++++++++++++++++++++++----------
 hw/s390x/s390-virtio.h     |  3 ++
 include/hw/nmi.h           | 49 +++++++++++++++++++++++++++
 qapi-schema.json           |  4 +--
 qmp-commands.hx            |  3 +-
 target-ppc/cpu-qom.h       |  1 +
 target-ppc/excp_helper.c   |  8 +++++
 13 files changed, 249 insertions(+), 56 deletions(-)
 create mode 100644 hw/core/nmi.c
 create mode 100644 include/hw/nmi.h

-- 
2.0.0

[Qemu-devel] [PATCH v7 1/4] cpus: Define callback for QEMU "nmi" command

[Alexey Kardashevskiy]

This introduces an NMI (Non Maskable Interrupt) interface with
a single nmi_monitor_handler() method. A machine or a device can
implement it. This searches for an QOM object with this interface
and if it is implemented, calls it. The callback implements an action
required to cause debug crash dump on in-kernel debugger invocation.
The callback returns Error**.

This adds a nmi_monitor_handle() helper which walks through
all objects to find the interface. The interface method is called
for all found instances.

This adds support for it in qmp_inject_nmi(). Since no architecture
supports it at the moment, there is no change in behaviour.

This changes inject-nmi command description for HMP and QMP.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v7:
* s/NMI/NMIState/
* added copyrighs to new files
* s/an Non/a Non/
* s/nmi()/nmi_monitor_handle()/

v6:
* NMI is an interface again

v5:
* s/given guest's (CPU|VCPU)/default CPU/
* nmi_monitor_handler() now returns Error**

v4:
* s/\<nmi\>/nmi_monitor_handler/

v3:
* actual nmi() enablement moved from last patch to first patch
* changed description for QMP command too
---
 cpus.c                |  3 +-
 hmp-commands.hx       |  6 ++--
 hw/core/Makefile.objs |  1 +
 hw/core/nmi.c         | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/hw/nmi.h      | 49 ++++++++++++++++++++++++++++++
 qapi-schema.json      |  4 +--
 qmp-commands.hx       |  3 +-
 7 files changed, 141 insertions(+), 9 deletions(-)
 create mode 100644 hw/core/nmi.c
 create mode 100644 include/hw/nmi.h

diff --git a/cpus.c b/cpus.c
index dd7ac13..5f357a4 100644
--- a/cpus.c
+++ b/cpus.c
@@ -38,6 +38,7 @@
 #include "qemu/main-loop.h"
 #include "qemu/bitmap.h"
 #include "qemu/seqlock.h"
+#include "hw/nmi.h"
 
 #ifndef _WIN32
 #include "qemu/compatfd.h"
@@ -1495,6 +1496,6 @@ void qmp_inject_nmi(Error **errp)
         }
     }
 #else
-    error_set(errp, QERR_UNSUPPORTED);
+    nmi_monitor_handle(monitor_get_cpu_index(), errp);
 #endif
 }
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 5f1a677..ff46b29 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -832,19 +832,17 @@ The values that can be specified here depend on the machine type, but are
 the same that can be specified in the @code{-boot} command line option.
 ETEXI
 
-#if defined(TARGET_I386) || defined(TARGET_S390X)
     {
         .name       = "nmi",
         .args_type  = "",
         .params     = "",
-        .help       = "inject an NMI on all guest's CPUs",
+        .help       = "inject an NMI",
         .mhandler.cmd = hmp_inject_nmi,
     },
-#endif
 STEXI
 @item nmi @var{cpu}
 @findex nmi
-Inject an NMI (x86) or RESTART (s390x) on the given CPU.
+Inject an NMI on the default CPU (x86/s390) or all CPUs (ppc64).
 
 ETEXI
 
diff --git a/hw/core/Makefile.objs b/hw/core/Makefile.objs
index 5377d05..17845df 100644
--- a/hw/core/Makefile.objs
+++ b/hw/core/Makefile.objs
@@ -4,6 +4,7 @@ common-obj-y += fw-path-provider.o
 # irq.o needed for qdev GPIO handling:
 common-obj-y += irq.o
 common-obj-y += hotplug.o
+common-obj-y += nmi.o
 
 common-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o
 common-obj-$(CONFIG_XILINX_AXI) += stream.o
diff --git a/hw/core/nmi.c b/hw/core/nmi.c
new file mode 100644
index 0000000..db1295f
--- /dev/null
+++ b/hw/core/nmi.c
@@ -0,0 +1,84 @@
+/*
+ *  NMI monitor handler class and helpers.
+ *
+ *  Copyright IBM Corp., 2014
+ *
+ *  Author: Alexey Kardashevskiy <aik@ozlabs.ru>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License,
+ *  or (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "hw/nmi.h"
+#include "qapi/qmp/qerror.h"
+
+struct do_nmi_s {
+    int cpu_index;
+    Error *errp;
+    bool handled;
+};
+
+static void nmi_children(Object *o, struct do_nmi_s *ns);
+
+static int do_nmi(Object *o, void *opaque)
+{
+    struct do_nmi_s *ns = opaque;
+    NMIState *n = (NMIState *) object_dynamic_cast(o, TYPE_NMI);
+
+    if (n) {
+        NMIClass *nc = NMI_GET_CLASS(n);
+
+        ns->handled = true;
+        nc->nmi_monitor_handler(n, ns->cpu_index, &ns->errp);
+        if (ns->errp) {
+            return -1;
+        }
+    }
+    nmi_children(o, ns);
+
+    return 0;
+}
+
+void nmi_children(Object *o, struct do_nmi_s *ns)
+{
+    object_child_foreach(o, do_nmi, ns);
+}
+
+void nmi_monitor_handle(int cpu_index, Error **errp)
+{
+    struct do_nmi_s ns = {
+        .cpu_index = cpu_index,
+        .errp = NULL,
+        .handled = false
+    };
+
+    nmi_children(object_get_root(), &ns);
+    if (ns.handled) {
+        error_propagate(errp, ns.errp);
+    } else {
+        error_set(errp, QERR_UNSUPPORTED);
+    }
+}
+
+static const TypeInfo nmi_info = {
+    .name          = TYPE_NMI,
+    .parent        = TYPE_INTERFACE,
+    .class_size    = sizeof(NMIClass),
+};
+
+static void nmi_register_types(void)
+{
+    type_register_static(&nmi_info);
+}
+
+type_init(nmi_register_types)
diff --git a/include/hw/nmi.h b/include/hw/nmi.h
new file mode 100644
index 0000000..b541772
--- /dev/null
+++ b/include/hw/nmi.h
@@ -0,0 +1,49 @@
+/*
+ *  NMI monitor handler class and helpers definitions.
+ *
+ *  Copyright IBM Corp., 2014
+ *
+ *  Author: Alexey Kardashevskiy <aik@ozlabs.ru>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License,
+ *  or (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef NMI_H
+#define NMI_H 1
+
+#include "qemu-common.h"
+#include "qom/object.h"
+
+#define TYPE_NMI "nmi"
+
+#define NMI_CLASS(klass) \
+     OBJECT_CLASS_CHECK(NMIClass, (klass), TYPE_NMI)
+#define NMI_GET_CLASS(obj) \
+    OBJECT_GET_CLASS(NMIClass, (obj), TYPE_NMI)
+#define NMI(obj) \
+     INTERFACE_CHECK(NMI, (obj), TYPE_NMI)
+
+typedef struct NMIState {
+    Object parent_obj;
+} NMIState;
+
+typedef struct NMIClass {
+    InterfaceClass parent_class;
+
+    void (*nmi_monitor_handler)(NMIState *n, int cpu_index, Error **errp);
+} NMIClass;
+
+void nmi_monitor_handle(int cpu_index, Error **errp);
+
+#endif /* NMI_H */
diff --git a/qapi-schema.json b/qapi-schema.json
index 14b498b..f468b55 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1116,13 +1116,13 @@
 ##
 # @inject-nmi:
 #
-# Injects an Non-Maskable Interrupt into all guest's VCPUs.
+# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
 #
 # Returns:  If successful, nothing
 #
 # Since:  0.14.0
 #
-# Notes: Only x86 Virtual Machines support this command.
+# Note: prior to 2.1, this command was only supported for x86 and s390 VMs
 ##
 { 'command': 'inject-nmi' }
 
diff --git a/qmp-commands.hx b/qmp-commands.hx
index d8aa4ed..0028d96 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -477,7 +477,7 @@ SQMP
 inject-nmi
 ----------
 
-Inject an NMI on guest's CPUs.
+Inject an NMI on the default CPU (x86/s390) or all CPUs (ppc64).
 
 Arguments: None.
 
@@ -487,7 +487,6 @@ Example:
 <- { "return": {} }
 
 Note: inject-nmi fails when the guest doesn't support injecting.
-      Currently, only x86 (NMI) and s390x (RESTART) guests do.
 
 EQMP
 
-- 
2.0.0

[Qemu-devel] [PATCH v7 2/4] s390x: Convert QEMUMachine to MachineClass

[Alexey Kardashevskiy]

This converts s390-virtio and s390-ccw-virtio machines to QOM MachineClass.
This brings ability to add interfaces to the machine classes. The first
interface for addition will be NMI.

The patch is mechanical so no change in behavior is expected.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
 hw/s390x/s390-virtio-ccw.c | 43 +++++++++++++++++++++++++++----------------
 hw/s390x/s390-virtio.c     | 44 +++++++++++++++++++++++++++-----------------
 2 files changed, 54 insertions(+), 33 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 42f5cec..05311b8 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -18,6 +18,8 @@
 #include "css.h"
 #include "virtio-ccw.h"
 
+#define TYPE_S390_CCW_MACHINE               "s390-ccw-machine"
+
 void io_subsystem_reset(void)
 {
     DeviceState *css, *sclp, *flic;
@@ -134,24 +136,33 @@ static void ccw_init(MachineState *machine)
     s390_create_virtio_net(BUS(css_bus), "virtio-net-ccw");
 }
 
-static QEMUMachine ccw_machine = {
-    .name = "s390-ccw-virtio",
-    .alias = "s390-ccw",
-    .desc = "VirtIO-ccw based S390 machine",
-    .init = ccw_init,
-    .block_default_type = IF_VIRTIO,
-    .no_cdrom = 1,
-    .no_floppy = 1,
-    .no_serial = 1,
-    .no_parallel = 1,
-    .no_sdcard = 1,
-    .use_sclp = 1,
-    .max_cpus = 255,
+static void ccw_machine_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    mc->name = "s390-ccw-virtio";
+    mc->alias = "s390-ccw";
+    mc->desc = "VirtIO-ccw based S390 machine";
+    mc->init = ccw_init;
+    mc->block_default_type = IF_VIRTIO;
+    mc->no_cdrom = 1;
+    mc->no_floppy = 1;
+    mc->no_serial = 1;
+    mc->no_parallel = 1;
+    mc->no_sdcard = 1;
+    mc->use_sclp = 1,
+    mc->max_cpus = 255;
+}
+
+static const TypeInfo ccw_machine_info = {
+    .name          = TYPE_S390_CCW_MACHINE,
+    .parent        = TYPE_MACHINE,
+    .class_init    = ccw_machine_class_init,
 };
 
-static void ccw_machine_init(void)
+static void ccw_machine_register_types(void)
 {
-    qemu_register_machine(&ccw_machine);
+    type_register_static(&ccw_machine_info);
 }
 
-machine_init(ccw_machine_init)
+type_init(ccw_machine_register_types)
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index 93c7ace..f1e0dbc 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -51,6 +51,7 @@
 
 #define MAX_BLK_DEVS                    10
 #define ZIPL_FILENAME                   "s390-zipl.rom"
+#define TYPE_S390_MACHINE               "s390-machine"
 
 static VirtIOS390Bus *s390_bus;
 static S390CPU **ipi_states;
@@ -279,25 +280,34 @@ static void s390_init(MachineState *machine)
     s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
 }
 
-static QEMUMachine s390_machine = {
-    .name = "s390-virtio",
-    .alias = "s390",
-    .desc = "VirtIO based S390 machine",
-    .init = s390_init,
-    .block_default_type = IF_VIRTIO,
-    .no_cdrom = 1,
-    .no_floppy = 1,
-    .no_serial = 1,
-    .no_parallel = 1,
-    .no_sdcard = 1,
-    .use_virtcon = 1,
-    .max_cpus = 255,
-    .is_default = 1,
+static void s390_machine_class_init(ObjectClass *oc, void *data)
+{
+    MachineClass *mc = MACHINE_CLASS(oc);
+
+    mc->name = "s390-virtio";
+    mc->alias = "s390";
+    mc->desc = "VirtIO based S390 machine";
+    mc->init = s390_init;
+    mc->block_default_type = IF_VIRTIO;
+    mc->max_cpus = 255;
+    mc->no_serial = 1;
+    mc->no_parallel = 1;
+    mc->use_virtcon = 1;
+    mc->no_floppy = 1;
+    mc->no_cdrom = 1;
+    mc->no_sdcard = 1;
+    mc->is_default = 1;
+}
+
+static const TypeInfo s390_machine_info = {
+    .name          = TYPE_S390_MACHINE,
+    .parent        = TYPE_MACHINE,
+    .class_init    = s390_machine_class_init,
 };
 
-static void s390_machine_init(void)
+static void s390_machine_register_types(void)
 {
-    qemu_register_machine(&s390_machine);
+    type_register_static(&s390_machine_info);
 }
 
-machine_init(s390_machine_init);
+type_init(s390_machine_register_types)
-- 
2.0.0

[Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

This implements an NMI interface for s390 and s390-ccw machines.

This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
nmi_monitor_handler() callback is going to be used for NMI.

Since nmi_monitor_handler()-calling code is platform independent,
CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
There should not be any change in behaviour as both @cpu_index and
@cpu_num are global CPU numbers.

Also, s390_cpu_restart() takes care of preforming operations in
the specific CPU thread so no extra measure is required here either.

Since the only error s390_cpu_restart() can return is ENOSYS, convert
it to QERR_UNSUPPORTED.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v7:
* since now s390' are QOM'ed, add interface to them and do not create
new object

v6:
* supported NMI interface

v5:
* added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this

v4:
* s/\<nmi\>/nmi_monitor_handler/

v3:
* now contains both old code removal and new code insertion, easier to
track changes

Conflicts:
	hw/s390x/s390-virtio.c
---
 cpus.c                     | 14 --------------
 hw/s390x/s390-virtio-ccw.c |  6 ++++++
 hw/s390x/s390-virtio.c     | 15 +++++++++++++++
 hw/s390x/s390-virtio.h     |  3 +++
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/cpus.c b/cpus.c
index 5f357a4..34bf5c5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1481,20 +1481,6 @@ void qmp_inject_nmi(Error **errp)
             apic_deliver_nmi(cpu->apic_state);
         }
     }
-#elif defined(TARGET_S390X)
-    CPUState *cs;
-    S390CPU *cpu;
-
-    CPU_FOREACH(cs) {
-        cpu = S390_CPU(cs);
-        if (cpu->env.cpu_num == monitor_get_cpu_index()) {
-            if (s390_cpu_restart(S390_CPU(cs)) == -1) {
-                error_set(errp, QERR_UNSUPPORTED);
-                return;
-            }
-            break;
-        }
-    }
 #else
     nmi_monitor_handle(monitor_get_cpu_index(), errp);
 #endif
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 05311b8..004b2c2 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -139,6 +139,7 @@ static void ccw_init(MachineState *machine)
 static void ccw_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    NMIClass *nc = NMI_CLASS(oc);
 
     mc->name = "s390-ccw-virtio";
     mc->alias = "s390-ccw";
@@ -152,12 +153,17 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
     mc->no_sdcard = 1;
     mc->use_sclp = 1,
     mc->max_cpus = 255;
+    nc->nmi_monitor_handler = s390_nmi;
 }
 
 static const TypeInfo ccw_machine_info = {
     .name          = TYPE_S390_CCW_MACHINE,
     .parent        = TYPE_MACHINE,
     .class_init    = ccw_machine_class_init,
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_NMI },
+        { }
+    },
 };
 
 static void ccw_machine_register_types(void)
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index f1e0dbc..1a75a1c 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -280,9 +280,19 @@ static void s390_init(MachineState *machine)
     s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
 }
 
+void s390_nmi(NMIState *n, int cpu_index, Error **errp)
+{
+    CPUState *cs = qemu_get_cpu(cpu_index);
+
+    if (s390_cpu_restart(S390_CPU(cs))) {
+        error_set(errp, QERR_UNSUPPORTED);
+    }
+}
+
 static void s390_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    NMIClass *nc = NMI_CLASS(oc);
 
     mc->name = "s390-virtio";
     mc->alias = "s390";
@@ -297,12 +307,17 @@ static void s390_machine_class_init(ObjectClass *oc, void *data)
     mc->no_cdrom = 1;
     mc->no_sdcard = 1;
     mc->is_default = 1;
+    nc->nmi_monitor_handler = s390_nmi;
 }
 
 static const TypeInfo s390_machine_info = {
     .name          = TYPE_S390_MACHINE,
     .parent        = TYPE_MACHINE,
     .class_init    = s390_machine_class_init,
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_NMI },
+        { }
+    },
 };
 
 static void s390_machine_register_types(void)
diff --git a/hw/s390x/s390-virtio.h b/hw/s390x/s390-virtio.h
index 5c405e7..33847ae 100644
--- a/hw/s390x/s390-virtio.h
+++ b/hw/s390x/s390-virtio.h
@@ -12,6 +12,8 @@
 #ifndef HW_S390_VIRTIO_H
 #define HW_S390_VIRTIO_H 1
 
+#include "hw/nmi.h"
+
 #define KVM_S390_VIRTIO_NOTIFY          0
 #define KVM_S390_VIRTIO_RESET           1
 #define KVM_S390_VIRTIO_SET_STATUS      2
@@ -26,4 +28,5 @@ void s390_init_ipl_dev(const char *kernel_filename,
                        const char *initrd_filename,
                        const char *firmware);
 void s390_create_virtio_net(BusState *bus, const char *name);
+void s390_nmi(NMIState *n, int cpu_index, Error **errp);
 #endif
-- 
2.0.0

[Qemu-devel] [PATCH v7 4/4] spapr: Add support for new NMI interface

[Alexey Kardashevskiy]

This implements an NMI interface POWERPC SPAPR machine.
This enables an "nmi" HMP/QMP command supported on SPAPR.

This calls POWERPC_EXCP_RESET (vector 0x100) in the guest to deliver NMI
to every CPU. The expected result is XMON (in-kernel debugger) invocation.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v7:
* s/ppc_cpu_do_nmi/ppc_cpu_do_system_reset/

v6:
* support NMI interface

v4:
* s/\<nmi\>/nmi_monitor_handler/
* added note about XMON into commit log

v3:
* ppc_cpu_do_nmi() is exported from excp_helper.c instead of powerpc_excp()
---
 hw/ppc/spapr.c           | 21 +++++++++++++++++++++
 target-ppc/cpu-qom.h     |  1 +
 target-ppc/excp_helper.c |  8 ++++++++
 3 files changed, 30 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 57e9578..34cbd1e 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -53,6 +53,7 @@
 #include "hw/usb.h"
 #include "qemu/config-file.h"
 #include "qemu/error-report.h"
+#include "hw/nmi.h"
 
 #include <libfdt.h>
 
@@ -1476,10 +1477,28 @@ static char *spapr_get_fw_dev_path(FWPathProvider *p, BusState *bus,
     return NULL;
 }
 
+static void ppc_cpu_do_nmi_on_cpu(void *arg)
+{
+    CPUState *cs = arg;
+
+    cpu_synchronize_state(cs);
+    ppc_cpu_do_system_reset(cs);
+}
+
+static void spapr_nmi(NMIState *n, int cpu_index, Error **errp)
+{
+    CPUState *cs;
+
+    CPU_FOREACH(cs) {
+        async_run_on_cpu(cs, ppc_cpu_do_nmi_on_cpu, cs);
+    }
+}
+
 static void spapr_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
     FWPathProviderClass *fwc = FW_PATH_PROVIDER_CLASS(oc);
+    NMIClass *nc = NMI_CLASS(oc);
 
     mc->name = "pseries";
     mc->desc = "pSeries Logical Partition (PAPR compliant)";
@@ -1493,6 +1512,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
     mc->kvm_type = spapr_kvm_type;
 
     fwc->get_dev_path = spapr_get_fw_dev_path;
+    nc->nmi_monitor_handler = spapr_nmi;
 }
 
 static const TypeInfo spapr_machine_info = {
@@ -1501,6 +1521,7 @@ static const TypeInfo spapr_machine_info = {
     .class_init    = spapr_machine_class_init,
     .interfaces = (InterfaceInfo[]) {
         { TYPE_FW_PATH_PROVIDER },
+        { TYPE_NMI },
         { }
     },
 };
diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index 47dc8e6..30f2a03 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -119,6 +119,7 @@ int ppc64_cpu_write_elf64_qemunote(WriteCoreDumpFunction f,
 int ppc64_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs,
                                int cpuid, void *opaque);
 #ifndef CONFIG_USER_ONLY
+void ppc_cpu_do_system_reset(CPUState *cs);
 extern const struct VMStateDescription vmstate_ppc_cpu;
 #endif
 
diff --git a/target-ppc/excp_helper.c b/target-ppc/excp_helper.c
index 7dfc52d..388392b 100644
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -802,6 +802,14 @@ void ppc_hw_interrupt(CPUPPCState *env)
         }
     }
 }
+
+void ppc_cpu_do_system_reset(CPUState *cs)
+{
+    PowerPCCPU *cpu = POWERPC_CPU(cs);
+    CPUPPCState *env = &cpu->env;
+
+    powerpc_excp(cpu, env->excp_model, POWERPC_EXCP_RESET);
+}
 #endif /* !CONFIG_USER_ONLY */
 
 #if defined(DEBUG_OP)
-- 
2.0.0

Re: [Qemu-devel] [PATCH v7 2/4] s390x: Convert QEMUMachine to MachineClass

[Alexey Kardashevskiy]

btw only this patche from the series got "[Qemu-devel]" in the subject line
and others did not, why? Lists of emails are almost the same, only Eric
Blake got kicked off (added him manually to this email cc:), is that
connected? :) Why is that subject thing happening? Thanks.



On 06/13/2014 01:36 PM, Alexey Kardashevskiy wrote:
> This converts s390-virtio and s390-ccw-virtio machines to QOM MachineClass.
> This brings ability to add interfaces to the machine classes. The first
> interface for addition will be NMI.
> 
> The patch is mechanical so no change in behavior is expected.
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>  hw/s390x/s390-virtio-ccw.c | 43 +++++++++++++++++++++++++++----------------
>  hw/s390x/s390-virtio.c     | 44 +++++++++++++++++++++++++++-----------------
>  2 files changed, 54 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index 42f5cec..05311b8 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -18,6 +18,8 @@
>  #include "css.h"
>  #include "virtio-ccw.h"
>  
> +#define TYPE_S390_CCW_MACHINE               "s390-ccw-machine"
> +
>  void io_subsystem_reset(void)
>  {
>      DeviceState *css, *sclp, *flic;
> @@ -134,24 +136,33 @@ static void ccw_init(MachineState *machine)
>      s390_create_virtio_net(BUS(css_bus), "virtio-net-ccw");
>  }
>  
> -static QEMUMachine ccw_machine = {
> -    .name = "s390-ccw-virtio",
> -    .alias = "s390-ccw",
> -    .desc = "VirtIO-ccw based S390 machine",
> -    .init = ccw_init,
> -    .block_default_type = IF_VIRTIO,
> -    .no_cdrom = 1,
> -    .no_floppy = 1,
> -    .no_serial = 1,
> -    .no_parallel = 1,
> -    .no_sdcard = 1,
> -    .use_sclp = 1,
> -    .max_cpus = 255,
> +static void ccw_machine_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
> +    mc->name = "s390-ccw-virtio";
> +    mc->alias = "s390-ccw";
> +    mc->desc = "VirtIO-ccw based S390 machine";
> +    mc->init = ccw_init;
> +    mc->block_default_type = IF_VIRTIO;
> +    mc->no_cdrom = 1;
> +    mc->no_floppy = 1;
> +    mc->no_serial = 1;
> +    mc->no_parallel = 1;
> +    mc->no_sdcard = 1;
> +    mc->use_sclp = 1,
> +    mc->max_cpus = 255;
> +}
> +
> +static const TypeInfo ccw_machine_info = {
> +    .name          = TYPE_S390_CCW_MACHINE,
> +    .parent        = TYPE_MACHINE,
> +    .class_init    = ccw_machine_class_init,
>  };
>  
> -static void ccw_machine_init(void)
> +static void ccw_machine_register_types(void)
>  {
> -    qemu_register_machine(&ccw_machine);
> +    type_register_static(&ccw_machine_info);
>  }
>  
> -machine_init(ccw_machine_init)
> +type_init(ccw_machine_register_types)
> diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
> index 93c7ace..f1e0dbc 100644
> --- a/hw/s390x/s390-virtio.c
> +++ b/hw/s390x/s390-virtio.c
> @@ -51,6 +51,7 @@
>  
>  #define MAX_BLK_DEVS                    10
>  #define ZIPL_FILENAME                   "s390-zipl.rom"
> +#define TYPE_S390_MACHINE               "s390-machine"
>  
>  static VirtIOS390Bus *s390_bus;
>  static S390CPU **ipi_states;
> @@ -279,25 +280,34 @@ static void s390_init(MachineState *machine)
>      s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
>  }
>  
> -static QEMUMachine s390_machine = {
> -    .name = "s390-virtio",
> -    .alias = "s390",
> -    .desc = "VirtIO based S390 machine",
> -    .init = s390_init,
> -    .block_default_type = IF_VIRTIO,
> -    .no_cdrom = 1,
> -    .no_floppy = 1,
> -    .no_serial = 1,
> -    .no_parallel = 1,
> -    .no_sdcard = 1,
> -    .use_virtcon = 1,
> -    .max_cpus = 255,
> -    .is_default = 1,
> +static void s390_machine_class_init(ObjectClass *oc, void *data)
> +{
> +    MachineClass *mc = MACHINE_CLASS(oc);
> +
> +    mc->name = "s390-virtio";
> +    mc->alias = "s390";
> +    mc->desc = "VirtIO based S390 machine";
> +    mc->init = s390_init;
> +    mc->block_default_type = IF_VIRTIO;
> +    mc->max_cpus = 255;
> +    mc->no_serial = 1;
> +    mc->no_parallel = 1;
> +    mc->use_virtcon = 1;
> +    mc->no_floppy = 1;
> +    mc->no_cdrom = 1;
> +    mc->no_sdcard = 1;
> +    mc->is_default = 1;
> +}
> +
> +static const TypeInfo s390_machine_info = {
> +    .name          = TYPE_S390_MACHINE,
> +    .parent        = TYPE_MACHINE,
> +    .class_init    = s390_machine_class_init,
>  };
>  
> -static void s390_machine_init(void)
> +static void s390_machine_register_types(void)
>  {
> -    qemu_register_machine(&s390_machine);
> +    type_register_static(&s390_machine_info);
>  }
>  
> -machine_init(s390_machine_init);
> +type_init(s390_machine_register_types)
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v7 2/4] s390x: Convert QEMUMachine to MachineClass

[Cornelia Huck]

On Fri, 13 Jun 2014 13:36:57 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> This converts s390-virtio and s390-ccw-virtio machines to QOM MachineClass.
> This brings ability to add interfaces to the machine classes. The first
> interface for addition will be NMI.
> 
> The patch is mechanical so no change in behavior is expected.
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>  hw/s390x/s390-virtio-ccw.c | 43 +++++++++++++++++++++++++++----------------
>  hw/s390x/s390-virtio.c     | 44 +++++++++++++++++++++++++++-----------------
>  2 files changed, 54 insertions(+), 33 deletions(-)
> 
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Cornelia Huck]

On Fri, 13 Jun 2014 13:36:58 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> This implements an NMI interface for s390 and s390-ccw machines.
> 
> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
> nmi_monitor_handler() callback is going to be used for NMI.
> 
> Since nmi_monitor_handler()-calling code is platform independent,
> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
> There should not be any change in behaviour as both @cpu_index and
> @cpu_num are global CPU numbers.
> 
> Also, s390_cpu_restart() takes care of preforming operations in
> the specific CPU thread so no extra measure is required here either.

I find this paragraph a bit confusing; I'd just remove it.

> 
> Since the only error s390_cpu_restart() can return is ENOSYS, convert
> it to QERR_UNSUPPORTED.
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> Changes:
> v7:
> * since now s390' are QOM'ed, add interface to them and do not create
> new object
> 
> v6:
> * supported NMI interface
> 
> v5:
> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
> 
> v4:
> * s/\<nmi\>/nmi_monitor_handler/
> 
> v3:
> * now contains both old code removal and new code insertion, easier to
> track changes
> 
> Conflicts:
> 	hw/s390x/s390-virtio.c
> ---
>  cpus.c                     | 14 --------------
>  hw/s390x/s390-virtio-ccw.c |  6 ++++++
>  hw/s390x/s390-virtio.c     | 15 +++++++++++++++
>  hw/s390x/s390-virtio.h     |  3 +++
>  4 files changed, 24 insertions(+), 14 deletions(-)
> 
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>

Re: [Qemu-devel] [PATCH v7 0/4] cpus: Add generic "nmi" monitor command support

[Alexander Graf]

On 13.06.14 05:36, Alexey Kardashevskiy wrote:
> This adds an "nmi" monitor command handler per CPUs.
> x86, s390 and ppc CPUS are supported.
>
> Please comment. Thanks.

I like it.

Reviewed-by: Alexander Graf <agraf@suse.de>


Alex

>
> Changes:
> v7:
> * fixed typenames, function names, copyrights
> * s390x QOM'ed for later addition of the NMI interface
> * Since none of x86 machines is QOM'ed, postpone migration to new interface for x86
>
> v6:
> * back 5 steps and make it an interface again
>
> v5:
> * added Error** to the callback
> * fixed some comments
>
> v4:
> * now it is not nmi() but nmi_monitor_handler() to avoid confusion
>
> v3:
> * patches reorganized
> * comments from v2 addressed, more details are in individual commit logs
>
> v2:
> * moved from machine interface to CPUClass callback
> * s390 and x86 moved to target-s390/target-i386
> * x86 handler delivers to the current CPU only now
>
>
>
>
> Alexey Kardashevskiy (4):
>    cpus: Define callback for QEMU "nmi" command
>    s390x: Convert QEMUMachine to MachineClass
>    s390x: Migrate to new NMI interface
>    spapr: Add support for new NMI interface
>
>   cpus.c                     | 17 ++--------
>   hmp-commands.hx            |  6 ++--
>   hw/core/Makefile.objs      |  1 +
>   hw/core/nmi.c              | 84 ++++++++++++++++++++++++++++++++++++++++++++++
>   hw/ppc/spapr.c             | 21 ++++++++++++
>   hw/s390x/s390-virtio-ccw.c | 49 ++++++++++++++++++---------
>   hw/s390x/s390-virtio.c     | 59 ++++++++++++++++++++++----------
>   hw/s390x/s390-virtio.h     |  3 ++
>   include/hw/nmi.h           | 49 +++++++++++++++++++++++++++
>   qapi-schema.json           |  4 +--
>   qmp-commands.hx            |  3 +-
>   target-ppc/cpu-qom.h       |  1 +
>   target-ppc/excp_helper.c   |  8 +++++
>   13 files changed, 249 insertions(+), 56 deletions(-)
>   create mode 100644 hw/core/nmi.c
>   create mode 100644 include/hw/nmi.h
>

Re: [Qemu-devel] [PATCH v7 2/4] s390x: Convert QEMUMachine to MachineClass

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On 06/12/2014 09:44 PM, Alexey Kardashevskiy wrote:
> btw only this patche from the series got "[Qemu-devel]" in the subject line
> and others did not, why? Lists of emails are almost the same, only Eric
> Blake got kicked off (added him manually to this email cc:), is that
> connected? :) Why is that subject thing happening? Thanks.

Mailman is stupid. If someone is subscribed to a list, and has enabled
the option to avoid duplicate mail from the list when they are also
listed in cc, then mailman stupidly thinks it should remove that person
from the cc list before broadcasting the message to the list.

If you see [Qemu-devel] in the subject line, you got the message through
mailman, and some cc's may have been stripped.  If you don't see the
prefix, then you got the mail directly through other means (probably
through being listed in cc).  Either way, I get the whole thread, but it
makes it rather arbitrary whether I get replies to the mail through the
list or in person, depending on whether others reply to their direct
mail or to the mail they got through the list.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 06/13/2014 04:00 PM, Cornelia Huck wrote:
> On Fri, 13 Jun 2014 13:36:58 +1000
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>> This implements an NMI interface for s390 and s390-ccw machines.
>>
>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>> nmi_monitor_handler() callback is going to be used for NMI.
>>
>> Since nmi_monitor_handler()-calling code is platform independent,
>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>> There should not be any change in behaviour as both @cpu_index and
>> @cpu_num are global CPU numbers.
>>
>> Also, s390_cpu_restart() takes care of preforming operations in
>> the specific CPU thread so no extra measure is required here either.
> 
> I find this paragraph a bit confusing; I'd just remove it.

Besides bad english (please feel free to adjust it), what else is confusing
here? I put it there because the spapr patch makes use of
async_run_on_cpu() and maintainers may ask why I do not do the same for
other platforms. This way I hoped I could reduce number of versions to post :)

> 
>>
>> Since the only error s390_cpu_restart() can return is ENOSYS, convert
>> it to QERR_UNSUPPORTED.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v7:
>> * since now s390' are QOM'ed, add interface to them and do not create
>> new object
>>
>> v6:
>> * supported NMI interface
>>
>> v5:
>> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
>>
>> v4:
>> * s/\<nmi\>/nmi_monitor_handler/
>>
>> v3:
>> * now contains both old code removal and new code insertion, easier to
>> track changes
>>
>> Conflicts:
>> 	hw/s390x/s390-virtio.c
>> ---
>>  cpus.c                     | 14 --------------
>>  hw/s390x/s390-virtio-ccw.c |  6 ++++++
>>  hw/s390x/s390-virtio.c     | 15 +++++++++++++++
>>  hw/s390x/s390-virtio.h     |  3 +++
>>  4 files changed, 24 insertions(+), 14 deletions(-)
>>
> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Cornelia Huck]

On Sat, 14 Jun 2014 12:41:50 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
> > On Fri, 13 Jun 2014 13:36:58 +1000
> > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > 
> >> This implements an NMI interface for s390 and s390-ccw machines.
> >>
> >> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
> >> nmi_monitor_handler() callback is going to be used for NMI.
> >>
> >> Since nmi_monitor_handler()-calling code is platform independent,
> >> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
> >> There should not be any change in behaviour as both @cpu_index and
> >> @cpu_num are global CPU numbers.
> >>
> >> Also, s390_cpu_restart() takes care of preforming operations in
> >> the specific CPU thread so no extra measure is required here either.
> > 
> > I find this paragraph a bit confusing; I'd just remove it.
> 
> Besides bad english (please feel free to adjust it), what else is confusing
> here? I put it there because the spapr patch makes use of
> async_run_on_cpu() and maintainers may ask why I do not do the same for
> other platforms. This way I hoped I could reduce number of versions to post :)

What about

"Note that s390_cpu_restart() already takes care of the specified cpu,
so we don't need to schedule via async_run_on_cpu()."

> 
> > 
> >>
> >> Since the only error s390_cpu_restart() can return is ENOSYS, convert
> >> it to QERR_UNSUPPORTED.
> >>
> >> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> >> ---
> >> Changes:
> >> v7:
> >> * since now s390' are QOM'ed, add interface to them and do not create
> >> new object
> >>
> >> v6:
> >> * supported NMI interface
> >>
> >> v5:
> >> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
> >>
> >> v4:
> >> * s/\<nmi\>/nmi_monitor_handler/
> >>
> >> v3:
> >> * now contains both old code removal and new code insertion, easier to
> >> track changes
> >>
> >> Conflicts:
> >> 	hw/s390x/s390-virtio.c
> >> ---
> >>  cpus.c                     | 14 --------------
> >>  hw/s390x/s390-virtio-ccw.c |  6 ++++++
> >>  hw/s390x/s390-virtio.c     | 15 +++++++++++++++
> >>  hw/s390x/s390-virtio.h     |  3 +++
> >>  4 files changed, 24 insertions(+), 14 deletions(-)
> >>
> > Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > 
> 
> 

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 06/16/2014 05:16 PM, Cornelia Huck wrote:
> On Sat, 14 Jun 2014 12:41:50 +1000
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>
>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>
>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>
>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>> There should not be any change in behaviour as both @cpu_index and
>>>> @cpu_num are global CPU numbers.
>>>>
>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>> the specific CPU thread so no extra measure is required here either.
>>>
>>> I find this paragraph a bit confusing; I'd just remove it.
>>
>> Besides bad english (please feel free to adjust it), what else is confusing
>> here? I put it there because the spapr patch makes use of
>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>> other platforms. This way I hoped I could reduce number of versions to post :)
> 
> What about
> 
> "Note that s390_cpu_restart() already takes care of the specified cpu,
> so we don't need to schedule via async_run_on_cpu()."

I fail to see how exactly this is better or different but ok :)


Alex, should I repost it with Cornelia's suggestion? What should happen
next to this patchset? Who is supposed to pick it up? Thanks.



>>
>>>
>>>>
>>>> Since the only error s390_cpu_restart() can return is ENOSYS, convert
>>>> it to QERR_UNSUPPORTED.
>>>>
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>> ---
>>>> Changes:
>>>> v7:
>>>> * since now s390' are QOM'ed, add interface to them and do not create
>>>> new object
>>>>
>>>> v6:
>>>> * supported NMI interface
>>>>
>>>> v5:
>>>> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
>>>>
>>>> v4:
>>>> * s/\<nmi\>/nmi_monitor_handler/
>>>>
>>>> v3:
>>>> * now contains both old code removal and new code insertion, easier to
>>>> track changes
>>>>
>>>> Conflicts:
>>>> 	hw/s390x/s390-virtio.c
>>>> ---
>>>>  cpus.c                     | 14 --------------
>>>>  hw/s390x/s390-virtio-ccw.c |  6 ++++++
>>>>  hw/s390x/s390-virtio.c     | 15 +++++++++++++++
>>>>  hw/s390x/s390-virtio.h     |  3 +++
>>>>  4 files changed, 24 insertions(+), 14 deletions(-)
>>>>
>>> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
>>>
>>
>>
> 


-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexander Graf]

On 16.06.14 10:33, Alexey Kardashevskiy wrote:
> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>> On Sat, 14 Jun 2014 12:41:50 +1000
>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>
>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>
>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>
>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>
>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>> @cpu_num are global CPU numbers.
>>>>>
>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>> the specific CPU thread so no extra measure is required here either.
>>>> I find this paragraph a bit confusing; I'd just remove it.
>>> Besides bad english (please feel free to adjust it), what else is confusing
>>> here? I put it there because the spapr patch makes use of
>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>> other platforms. This way I hoped I could reduce number of versions to post :)
>> What about
>>
>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>> so we don't need to schedule via async_run_on_cpu()."
> I fail to see how exactly this is better or different but ok :)
>
>
> Alex, should I repost it with Cornelia's suggestion? What should happen
> next to this patchset? Who is supposed to pick it up? Thanks.

Just post v8 of that single patch with the right message-id as 
reference. I can pick up the patches, but I'd like at least an ack from 
Paolo on the whole set.


Alex

[Qemu-devel] [PATCH v8] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

This implements an NMI interface for s390 and s390-ccw machines.

This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
nmi_monitor_handler() callback is going to be used for NMI.

Since nmi_monitor_handler()-calling code is platform independent,
CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
There should not be any change in behaviour as both @cpu_index and
@cpu_num are global CPU numbers.

Note that s390_cpu_restart() already takes care of the specified cpu,
so we don't need to schedule via async_run_on_cpu().

Since the only error s390_cpu_restart() can return is ENOSYS, convert
it to QERR_UNSUPPORTED.

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v8:
* adjusted commit log

v7:
* since now s390' are QOM'ed, add interface to them and do not create
new object

v6:
* supported NMI interface

v5:
* added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this

v4:
* s/\<nmi\>/nmi_monitor_handler/

v3:
* now contains both old code removal and new code insertion, easier to
track changes

Conflicts:
	hw/s390x/s390-virtio.c
---
 cpus.c                     | 14 --------------
 hw/s390x/s390-virtio-ccw.c |  6 ++++++
 hw/s390x/s390-virtio.c     | 15 +++++++++++++++
 hw/s390x/s390-virtio.h     |  3 +++
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/cpus.c b/cpus.c
index 5f357a4..34bf5c5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1481,20 +1481,6 @@ void qmp_inject_nmi(Error **errp)
             apic_deliver_nmi(cpu->apic_state);
         }
     }
-#elif defined(TARGET_S390X)
-    CPUState *cs;
-    S390CPU *cpu;
-
-    CPU_FOREACH(cs) {
-        cpu = S390_CPU(cs);
-        if (cpu->env.cpu_num == monitor_get_cpu_index()) {
-            if (s390_cpu_restart(S390_CPU(cs)) == -1) {
-                error_set(errp, QERR_UNSUPPORTED);
-                return;
-            }
-            break;
-        }
-    }
 #else
     nmi_monitor_handle(monitor_get_cpu_index(), errp);
 #endif
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 05311b8..004b2c2 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -139,6 +139,7 @@ static void ccw_init(MachineState *machine)
 static void ccw_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    NMIClass *nc = NMI_CLASS(oc);
 
     mc->name = "s390-ccw-virtio";
     mc->alias = "s390-ccw";
@@ -152,12 +153,17 @@ static void ccw_machine_class_init(ObjectClass *oc, void *data)
     mc->no_sdcard = 1;
     mc->use_sclp = 1,
     mc->max_cpus = 255;
+    nc->nmi_monitor_handler = s390_nmi;
 }
 
 static const TypeInfo ccw_machine_info = {
     .name          = TYPE_S390_CCW_MACHINE,
     .parent        = TYPE_MACHINE,
     .class_init    = ccw_machine_class_init,
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_NMI },
+        { }
+    },
 };
 
 static void ccw_machine_register_types(void)
diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c
index f1e0dbc..1a75a1c 100644
--- a/hw/s390x/s390-virtio.c
+++ b/hw/s390x/s390-virtio.c
@@ -280,9 +280,19 @@ static void s390_init(MachineState *machine)
     s390_create_virtio_net((BusState *)s390_bus, "virtio-net-s390");
 }
 
+void s390_nmi(NMIState *n, int cpu_index, Error **errp)
+{
+    CPUState *cs = qemu_get_cpu(cpu_index);
+
+    if (s390_cpu_restart(S390_CPU(cs))) {
+        error_set(errp, QERR_UNSUPPORTED);
+    }
+}
+
 static void s390_machine_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
+    NMIClass *nc = NMI_CLASS(oc);
 
     mc->name = "s390-virtio";
     mc->alias = "s390";
@@ -297,12 +307,17 @@ static void s390_machine_class_init(ObjectClass *oc, void *data)
     mc->no_cdrom = 1;
     mc->no_sdcard = 1;
     mc->is_default = 1;
+    nc->nmi_monitor_handler = s390_nmi;
 }
 
 static const TypeInfo s390_machine_info = {
     .name          = TYPE_S390_MACHINE,
     .parent        = TYPE_MACHINE,
     .class_init    = s390_machine_class_init,
+    .interfaces = (InterfaceInfo[]) {
+        { TYPE_NMI },
+        { }
+    },
 };
 
 static void s390_machine_register_types(void)
diff --git a/hw/s390x/s390-virtio.h b/hw/s390x/s390-virtio.h
index 5c405e7..33847ae 100644
--- a/hw/s390x/s390-virtio.h
+++ b/hw/s390x/s390-virtio.h
@@ -12,6 +12,8 @@
 #ifndef HW_S390_VIRTIO_H
 #define HW_S390_VIRTIO_H 1
 
+#include "hw/nmi.h"
+
 #define KVM_S390_VIRTIO_NOTIFY          0
 #define KVM_S390_VIRTIO_RESET           1
 #define KVM_S390_VIRTIO_SET_STATUS      2
@@ -26,4 +28,5 @@ void s390_init_ipl_dev(const char *kernel_filename,
                        const char *initrd_filename,
                        const char *firmware);
 void s390_create_virtio_net(BusState *bus, const char *name);
+void s390_nmi(NMIState *n, int cpu_index, Error **errp);
 #endif
-- 
2.0.0

Re: [Qemu-devel] [PATCH v8] s390x: Migrate to new NMI interface

[Cornelia Huck]

On Mon, 16 Jun 2014 18:57:45 +1000
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> This implements an NMI interface for s390 and s390-ccw machines.
> 
> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
> nmi_monitor_handler() callback is going to be used for NMI.
> 
> Since nmi_monitor_handler()-calling code is platform independent,
> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
> There should not be any change in behaviour as both @cpu_index and
> @cpu_num are global CPU numbers.
> 
> Note that s390_cpu_restart() already takes care of the specified cpu,
> so we don't need to schedule via async_run_on_cpu().
> 
> Since the only error s390_cpu_restart() can return is ENOSYS, convert
> it to QERR_UNSUPPORTED.
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>

Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>

> ---
> Changes:
> v8:
> * adjusted commit log
> 
> v7:
> * since now s390' are QOM'ed, add interface to them and do not create
> new object
> 
> v6:
> * supported NMI interface
> 
> v5:
> * added ENOSYS -> QERR_UNSUPPORTED, qapi/qmp/qerror.h was added for this
> 
> v4:
> * s/\<nmi\>/nmi_monitor_handler/
> 
> v3:
> * now contains both old code removal and new code insertion, easier to
> track changes
> 
> Conflicts:
> 	hw/s390x/s390-virtio.c
> ---
>  cpus.c                     | 14 --------------
>  hw/s390x/s390-virtio-ccw.c |  6 ++++++
>  hw/s390x/s390-virtio.c     | 15 +++++++++++++++
>  hw/s390x/s390-virtio.h     |  3 +++
>  4 files changed, 24 insertions(+), 14 deletions(-)
> 

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 06/16/2014 06:37 PM, Alexander Graf wrote:
> 
> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>> On Sat, 14 Jun 2014 12:41:50 +1000
>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>
>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>
>>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>>
>>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>>
>>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>>> @cpu_num are global CPU numbers.
>>>>>>
>>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>>> the specific CPU thread so no extra measure is required here either.
>>>>> I find this paragraph a bit confusing; I'd just remove it.
>>>> Besides bad english (please feel free to adjust it), what else is
>>>> confusing
>>>> here? I put it there because the spapr patch makes use of
>>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>>> other platforms. This way I hoped I could reduce number of versions to
>>>> post :)
>>> What about
>>>
>>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>>> so we don't need to schedule via async_run_on_cpu()."
>> I fail to see how exactly this is better or different but ok :)
>>
>>
>> Alex, should I repost it with Cornelia's suggestion? What should happen
>> next to this patchset? Who is supposed to pick it up? Thanks.
> 
> Just post v8 of that single patch with the right message-id as reference. I
> can pick up the patches, but I'd like at least an ack from Paolo on the
> whole set.


Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll
repost it with x86 NMI handler? Thanks!



-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
> On 06/16/2014 06:37 PM, Alexander Graf wrote:
>>
>> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>>> On Sat, 14 Jun 2014 12:41:50 +1000
>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>
>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>
>>>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>>>
>>>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>>>
>>>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>>>> @cpu_num are global CPU numbers.
>>>>>>>
>>>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>>>> the specific CPU thread so no extra measure is required here either.
>>>>>> I find this paragraph a bit confusing; I'd just remove it.
>>>>> Besides bad english (please feel free to adjust it), what else is
>>>>> confusing
>>>>> here? I put it there because the spapr patch makes use of
>>>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>>>> other platforms. This way I hoped I could reduce number of versions to
>>>>> post :)
>>>> What about
>>>>
>>>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>>>> so we don't need to schedule via async_run_on_cpu()."
>>> I fail to see how exactly this is better or different but ok :)
>>>
>>>
>>> Alex, should I repost it with Cornelia's suggestion? What should happen
>>> next to this patchset? Who is supposed to pick it up? Thanks.
>>
>> Just post v8 of that single patch with the right message-id as reference. I
>> can pick up the patches, but I'd like at least an ack from Paolo on the
>> whole set.
> 
> 
> Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll
> repost it with x86 NMI handler? Thanks!


Paolo promised to ack (in irc) and obviously forgot :) Should I give up and
stop bothering noble people? :)



-- 
Alexey

Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 1/4] cpus: Define callback for QEMU "nmi" command

[Nikunj A Dadhania]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> diff --git a/hw/core/nmi.c b/hw/core/nmi.c
> new file mode 100644
> index 0000000..db1295f
> --- /dev/null
> +++ b/hw/core/nmi.c
> @@ -0,0 +1,84 @@

[...]

> +
> +static void nmi_children(Object *o, struct do_nmi_s *ns);
> +

[...]

> +
> +void nmi_children(Object *o, struct do_nmi_s *ns)

Above declared as static and implemented non-static.

Regards
Nikunj

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Markus Armbruster]

Alexey Kardashevskiy <aik@ozlabs.ru> writes:

> On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
>> On 06/16/2014 06:37 PM, Alexander Graf wrote:
>>>
>>> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>>>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>>>> On Sat, 14 Jun 2014 12:41:50 +1000
>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>
>>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>
>>>>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>>>>
>>>>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>>>>
>>>>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>>>>> @cpu_num are global CPU numbers.
>>>>>>>>
>>>>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>>>>> the specific CPU thread so no extra measure is required here either.
>>>>>>> I find this paragraph a bit confusing; I'd just remove it.
>>>>>> Besides bad english (please feel free to adjust it), what else is
>>>>>> confusing
>>>>>> here? I put it there because the spapr patch makes use of
>>>>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>>>>> other platforms. This way I hoped I could reduce number of versions to
>>>>>> post :)
>>>>> What about
>>>>>
>>>>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>>>>> so we don't need to schedule via async_run_on_cpu()."
>>>> I fail to see how exactly this is better or different but ok :)
>>>>
>>>>
>>>> Alex, should I repost it with Cornelia's suggestion? What should happen
>>>> next to this patchset? Who is supposed to pick it up? Thanks.
>>>
>>> Just post v8 of that single patch with the right message-id as reference. I
>>> can pick up the patches, but I'd like at least an ack from Paolo on the
>>> whole set.
>> 
>> 
>> Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll
>> repost it with x86 NMI handler? Thanks!
>
>
> Paolo promised to ack (in irc) and obviously forgot :) Should I give up and
> stop bothering noble people? :)

No, you should politely bother them again.

Re: [Qemu-devel] [Qemu-ppc] [PATCH v7 1/4] cpus: Define callback for QEMU "nmi" command

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On 07/03/2014 12:41 AM, Nikunj A Dadhania wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
>> diff --git a/hw/core/nmi.c b/hw/core/nmi.c
>> new file mode 100644
>> index 0000000..db1295f
>> --- /dev/null
>> +++ b/hw/core/nmi.c
>> @@ -0,0 +1,84 @@
> 
> [...]
> 
>> +
>> +static void nmi_children(Object *o, struct do_nmi_s *ns);
>> +
> 
> [...]
> 
>> +
>> +void nmi_children(Object *o, struct do_nmi_s *ns)
> 
> Above declared as static and implemented non-static.

No, it is implemented as static, by definition of the C language (the
compiler does not require you to repeat the 'static', but it still
honors all attributes present on either the declaration or the
implementation).  Although you are right that it looks inconsistent.

On the other hand, if the function is not mutually recursive with
something else in the file, I personally prefer hoisting static
functions to be implemented in topological order, instead of finding a
static declaration and then having to hunt for the body.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 07/03/2014 05:11 PM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
>>> On 06/16/2014 06:37 PM, Alexander Graf wrote:
>>>>
>>>> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>>>>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
>>>>>> On Sat, 14 Jun 2014 12:41:50 +1000
>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>
>>>>>>> On 06/13/2014 04:00 PM, Cornelia Huck wrote:
>>>>>>>> On Fri, 13 Jun 2014 13:36:58 +1000
>>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>>
>>>>>>>>> This implements an NMI interface for s390 and s390-ccw machines.
>>>>>>>>>
>>>>>>>>> This removes #ifdef s390 branch in qmp_inject_nmi so new s390's
>>>>>>>>> nmi_monitor_handler() callback is going to be used for NMI.
>>>>>>>>>
>>>>>>>>> Since nmi_monitor_handler()-calling code is platform independent,
>>>>>>>>> CPUState::cpu_index is used instead of S390CPU::env.cpu_num.
>>>>>>>>> There should not be any change in behaviour as both @cpu_index and
>>>>>>>>> @cpu_num are global CPU numbers.
>>>>>>>>>
>>>>>>>>> Also, s390_cpu_restart() takes care of preforming operations in
>>>>>>>>> the specific CPU thread so no extra measure is required here either.
>>>>>>>> I find this paragraph a bit confusing; I'd just remove it.
>>>>>>> Besides bad english (please feel free to adjust it), what else is
>>>>>>> confusing
>>>>>>> here? I put it there because the spapr patch makes use of
>>>>>>> async_run_on_cpu() and maintainers may ask why I do not do the same for
>>>>>>> other platforms. This way I hoped I could reduce number of versions to
>>>>>>> post :)
>>>>>> What about
>>>>>>
>>>>>> "Note that s390_cpu_restart() already takes care of the specified cpu,
>>>>>> so we don't need to schedule via async_run_on_cpu()."
>>>>> I fail to see how exactly this is better or different but ok :)
>>>>>
>>>>>
>>>>> Alex, should I repost it with Cornelia's suggestion? What should happen
>>>>> next to this patchset? Who is supposed to pick it up? Thanks.
>>>>
>>>> Just post v8 of that single patch with the right message-id as reference. I
>>>> can pick up the patches, but I'd like at least an ack from Paolo on the
>>>> whole set.
>>>
>>>
>>> Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll
>>> repost it with x86 NMI handler? Thanks!
>>
>>
>> Paolo promised to ack (in irc) and obviously forgot :) Should I give up and
>> stop bothering noble people? :)
> 
> No, you should politely bother them again.


That does not seem helping though :-/



-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Paolo Bonzini]

Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>> > No, you should politely bother them again.
>
> That does not seem helping though :-/

Sorry. :)

Well, patch 1 is the same as v6 and for the others Cornelia and Alex can 
ack it.  It looks good to me though.

Paolo

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Cornelia Huck]

On Mon, 14 Jul 2014 22:29:50 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
> >> > No, you should politely bother them again.
> >
> > That does not seem helping though :-/
> 
> Sorry. :)
> 
> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can 
> ack it.  It looks good to me though.

I had r-b'd v8 of this patch and v7 of the other s390x patch, and the
whole series looks fine to me.

Re: [Qemu-devel] [PATCH v7 1/4] cpus: Define callback for QEMU "nmi" command

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

On 06/12/2014 09:36 PM, Alexey Kardashevskiy wrote:
> This introduces an NMI (Non Maskable Interrupt) interface with
> a single nmi_monitor_handler() method. A machine or a device can
> implement it. This searches for an QOM object with this interface
> and if it is implemented, calls it. The callback implements an action
> required to cause debug crash dump on in-kernel debugger invocation.
> The callback returns Error**.
> 
> This adds a nmi_monitor_handle() helper which walks through
> all objects to find the interface. The interface method is called
> for all found instances.
> 
> This adds support for it in qmp_inject_nmi(). Since no architecture
> supports it at the moment, there is no change in behaviour.
> 
> This changes inject-nmi command description for HMP and QMP.
> 
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---

> +++ b/qapi-schema.json
> @@ -1116,13 +1116,13 @@
>  ##
>  # @inject-nmi:
>  #
> -# Injects an Non-Maskable Interrupt into all guest's VCPUs.
> +# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
>  #
>  # Returns:  If successful, nothing
>  #
>  # Since:  0.14.0
>  #
> -# Notes: Only x86 Virtual Machines support this command.
> +# Note: prior to 2.1, this command was only supported for x86 and s390 VMs

Are we still trying to get this into 2.1, or has it slipped to 2.2?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [PATCH v7 1/4] cpus: Define callback for QEMU "nmi" command

[Peter Maydell]

On 15 July 2014 15:50, Eric Blake <eblake@redhat.com> wrote:
> On 06/12/2014 09:36 PM, Alexey Kardashevskiy wrote:
>> This introduces an NMI (Non Maskable Interrupt) interface with
>> a single nmi_monitor_handler() method. A machine or a device can
>> implement it. This searches for an QOM object with this interface
>> and if it is implemented, calls it. The callback implements an action
>> required to cause debug crash dump on in-kernel debugger invocation.
>> The callback returns Error**.
>>
>> This adds a nmi_monitor_handle() helper which walks through
>> all objects to find the interface. The interface method is called
>> for all found instances.
>>
>> This adds support for it in qmp_inject_nmi(). Since no architecture
>> supports it at the moment, there is no change in behaviour.
>>
>> This changes inject-nmi command description for HMP and QMP.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>
>> +++ b/qapi-schema.json
>> @@ -1116,13 +1116,13 @@
>>  ##
>>  # @inject-nmi:
>>  #
>> -# Injects an Non-Maskable Interrupt into all guest's VCPUs.
>> +# Injects a Non-Maskable Interrupt into the default CPU (x86/s390) or all CPUs (ppc64).
>>  #
>>  # Returns:  If successful, nothing
>>  #
>>  # Since:  0.14.0
>>  #
>> -# Notes: Only x86 Virtual Machines support this command.
>> +# Note: prior to 2.1, this command was only supported for x86 and s390 VMs
>
> Are we still trying to get this into 2.1, or has it slipped to 2.2?

I think this is definitely too late at this point.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>> > No, you should politely bother them again.
>>
>> That does not seem helping though :-/
> 
> Sorry. :)
> 
> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
> ack it.  It looks good to me though.


Let me clarify things here.

Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
repost after 2.1 is released and resume annoying people again. Is that correct?

This is my current set:
5/5 pc_piix: Migrate to new NMI interface
4/5 spapr: Add support for new NMI interface
3/5 s390x: Migrate to new NMI interface
2/5 s390x: Convert QEMUMachine to MachineClass
1/5 cpus: Define callback for QEMU "nmi" command



-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>> No, you should politely bother them again.
>>>
>>> That does not seem helping though :-/
>>
>> Sorry. :)
>>
>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>> ack it.  It looks good to me though.
> 
> 
> Let me clarify things here.
> 
> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
> repost after 2.1 is released and resume annoying people again. Is that correct?
> 
> This is my current set:
> 5/5 pc_piix: Migrate to new NMI interface
> 4/5 spapr: Add support for new NMI interface
> 3/5 s390x: Migrate to new NMI interface
> 2/5 s390x: Convert QEMUMachine to MachineClass
> 1/5 cpus: Define callback for QEMU "nmi" command


Alex, ping.


ps. anecdot.
"what is your problem?"
"doctor, everybody ignores me"
"ah I see. next patient, please"
:)





-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexander Graf]

On 20.08.14 12:20, Alexey Kardashevskiy wrote:
> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>> No, you should politely bother them again.
>>>>
>>>> That does not seem helping though :-/
>>>
>>> Sorry. :)
>>>
>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>> ack it.  It looks good to me though.
>>
>>
>> Let me clarify things here.
>>
>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>
>> This is my current set:
>> 5/5 pc_piix: Migrate to new NMI interface
>> 4/5 spapr: Add support for new NMI interface
>> 3/5 s390x: Migrate to new NMI interface
>> 2/5 s390x: Convert QEMUMachine to MachineClass
>> 1/5 cpus: Define callback for QEMU "nmi" command
> 
> 
> Alex, ping.
>


Uh, what exactly do you expect from me? :)


Alex

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 08/20/2014 09:20 PM, Alexander Graf wrote:
> 
> 
> On 20.08.14 12:20, Alexey Kardashevskiy wrote:
>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>>> No, you should politely bother them again.
>>>>>
>>>>> That does not seem helping though :-/
>>>>
>>>> Sorry. :)
>>>>
>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>>> ack it.  It looks good to me though.
>>>
>>>
>>> Let me clarify things here.
>>>
>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>>
>>> This is my current set:
>>> 5/5 pc_piix: Migrate to new NMI interface
>>> 4/5 spapr: Add support for new NMI interface
>>> 3/5 s390x: Migrate to new NMI interface
>>> 2/5 s390x: Convert QEMUMachine to MachineClass
>>> 1/5 cpus: Define callback for QEMU "nmi" command
>>
>>
>> Alex, ping.
>>
> 
> 
> Uh, what exactly do you expect from me? :)

No idea :) You could take patches to your tree. I do not understand what to
do with this set now. Please help. Thanks.



-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexander Graf]

On 20.08.14 13:38, Alexey Kardashevskiy wrote:
> On 08/20/2014 09:20 PM, Alexander Graf wrote:
>>
>>
>> On 20.08.14 12:20, Alexey Kardashevskiy wrote:
>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>>>> No, you should politely bother them again.
>>>>>>
>>>>>> That does not seem helping though :-/
>>>>>
>>>>> Sorry. :)
>>>>>
>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>>>> ack it.  It looks good to me though.
>>>>
>>>>
>>>> Let me clarify things here.
>>>>
>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>>>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>>>
>>>> This is my current set:
>>>> 5/5 pc_piix: Migrate to new NMI interface
>>>> 4/5 spapr: Add support for new NMI interface
>>>> 3/5 s390x: Migrate to new NMI interface
>>>> 2/5 s390x: Convert QEMUMachine to MachineClass
>>>> 1/5 cpus: Define callback for QEMU "nmi" command
>>>
>>>
>>> Alex, ping.
>>>
>>
>>
>> Uh, what exactly do you expect from me? :)
> 
> No idea :) You could take patches to your tree. I do not understand what to
> do with this set now. Please help. Thanks.

The way I understood your last email you wanted to rebase and repost
them at which point someone could pick them up :)


Alex

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexey Kardashevskiy]

On 08/20/2014 10:05 PM, Alexander Graf wrote:
> 
> 
> On 20.08.14 13:38, Alexey Kardashevskiy wrote:
>> On 08/20/2014 09:20 PM, Alexander Graf wrote:
>>>
>>>
>>> On 20.08.14 12:20, Alexey Kardashevskiy wrote:
>>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>>>>> No, you should politely bother them again.
>>>>>>>
>>>>>>> That does not seem helping though :-/
>>>>>>
>>>>>> Sorry. :)
>>>>>>
>>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>>>>> ack it.  It looks good to me though.
>>>>>
>>>>>
>>>>> Let me clarify things here.
>>>>>
>>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>>>>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>>>>
>>>>> This is my current set:
>>>>> 5/5 pc_piix: Migrate to new NMI interface
>>>>> 4/5 spapr: Add support for new NMI interface
>>>>> 3/5 s390x: Migrate to new NMI interface
>>>>> 2/5 s390x: Convert QEMUMachine to MachineClass
>>>>> 1/5 cpus: Define callback for QEMU "nmi" command
>>>>
>>>>
>>>> Alex, ping.
>>>>
>>>
>>>
>>> Uh, what exactly do you expect from me? :)
>>
>> No idea :) You could take patches to your tree. I do not understand what to
>> do with this set now. Please help. Thanks.
> 
> The way I understood your last email you wanted to rebase and repost
> them at which point someone could pick them up :)

I wanted answer to "is that correct?" :)
And I tried replaying the patchset on top of your ppc-next, it applied. But
I'll repost to make sure that we have the same thing.



-- 
Alexey

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Alexander Graf]

On 20.08.14 14:11, Alexey Kardashevskiy wrote:
> On 08/20/2014 10:05 PM, Alexander Graf wrote:
>>
>>
>> On 20.08.14 13:38, Alexey Kardashevskiy wrote:
>>> On 08/20/2014 09:20 PM, Alexander Graf wrote:
>>>>
>>>>
>>>> On 20.08.14 12:20, Alexey Kardashevskiy wrote:
>>>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>>>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>>>>>> No, you should politely bother them again.
>>>>>>>>
>>>>>>>> That does not seem helping though :-/
>>>>>>>
>>>>>>> Sorry. :)
>>>>>>>
>>>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>>>>>> ack it.  It looks good to me though.
>>>>>>
>>>>>>
>>>>>> Let me clarify things here.
>>>>>>
>>>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>>>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>>>>>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>>>>>
>>>>>> This is my current set:
>>>>>> 5/5 pc_piix: Migrate to new NMI interface
>>>>>> 4/5 spapr: Add support for new NMI interface
>>>>>> 3/5 s390x: Migrate to new NMI interface
>>>>>> 2/5 s390x: Convert QEMUMachine to MachineClass
>>>>>> 1/5 cpus: Define callback for QEMU "nmi" command
>>>>>
>>>>>
>>>>> Alex, ping.
>>>>>
>>>>
>>>>
>>>> Uh, what exactly do you expect from me? :)
>>>
>>> No idea :) You could take patches to your tree. I do not understand what to
>>> do with this set now. Please help. Thanks.
>>
>> The way I understood your last email you wanted to rebase and repost
>> them at which point someone could pick them up :)
> 
> I wanted answer to "is that correct?" :)
> And I tried replaying the patchset on top of your ppc-next, it applied. But
> I'll repost to make sure that we have the same thing.

Oh, cool. I'll apply them as soon as I finished to recover my HD then :)


Alex

Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface

[Paolo Bonzini]

Il 20/08/2014 14:12, Alexander Graf ha scritto:
> 
> 
> On 20.08.14 14:11, Alexey Kardashevskiy wrote:
>> On 08/20/2014 10:05 PM, Alexander Graf wrote:
>>>
>>>
>>> On 20.08.14 13:38, Alexey Kardashevskiy wrote:
>>>> On 08/20/2014 09:20 PM, Alexander Graf wrote:
>>>>>
>>>>>
>>>>> On 20.08.14 12:20, Alexey Kardashevskiy wrote:
>>>>>> On 07/17/2014 04:30 PM, Alexey Kardashevskiy wrote:
>>>>>>> On 07/15/2014 06:29 AM, Paolo Bonzini wrote:
>>>>>>>> Il 14/07/2014 05:17, Alexey Kardashevskiy ha scritto:
>>>>>>>>>>> No, you should politely bother them again.
>>>>>>>>>
>>>>>>>>> That does not seem helping though :-/
>>>>>>>>
>>>>>>>> Sorry. :)
>>>>>>>>
>>>>>>>> Well, patch 1 is the same as v6 and for the others Cornelia and Alex can
>>>>>>>> ack it.  It looks good to me though.
>>>>>>>
>>>>>>>
>>>>>>> Let me clarify things here.
>>>>>>>
>>>>>>> Alex rb'ed to 0/4, Cornelia rb'ed 2/4 and 3/4, so I put Alex's rb to
>>>>>>> 1&2&3&4&5, Cornelia's rb to 2&3, rebase it on top of the current upstream,
>>>>>>> repost after 2.1 is released and resume annoying people again. Is that correct?
>>>>>>>
>>>>>>> This is my current set:
>>>>>>> 5/5 pc_piix: Migrate to new NMI interface
>>>>>>> 4/5 spapr: Add support for new NMI interface
>>>>>>> 3/5 s390x: Migrate to new NMI interface
>>>>>>> 2/5 s390x: Convert QEMUMachine to MachineClass
>>>>>>> 1/5 cpus: Define callback for QEMU "nmi" command
>>>>>>
>>>>>>
>>>>>> Alex, ping.
>>>>>>
>>>>>
>>>>>
>>>>> Uh, what exactly do you expect from me? :)
>>>>
>>>> No idea :) You could take patches to your tree. I do not understand what to
>>>> do with this set now. Please help. Thanks.
>>>
>>> The way I understood your last email you wanted to rebase and repost
>>> them at which point someone could pick them up :)
>>
>> I wanted answer to "is that correct?" :)
>> And I tried replaying the patchset on top of your ppc-next, it applied. But
>> I'll repost to make sure that we have the same thing.
> 
> Oh, cool. I'll apply them as soon as I finished to recover my HD then :)

I can apply them to uq/master too.  Let me know.

Paolo