Commit bb9bf94b authored by Peter Maydell's avatar Peter Maydell
Browse files

Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging



Machine queue post-3.1.0 (including 4.0 machine-types)

Features:
* Add 4.0 machine-types to q35/440fx/arm/spapr (Alex Williamson)

Documentation:
* Document vCPU hotplug procedure (Kashyap Chamarthy)
* Deprecate `cpu-add` monitor commands (Kashyap Chamarthy)

Bug fixes:
* A small sun4v_rtc_write() tracing fix that fell through the cracks
  (Eduardo Habkost)
* Validation of "host-nodes" option on memory backends (Eduardo Habkost)
* memory-device fixes and cleanups (David Hildenbrand)

Cleanups:
* Machine-type code cleanup (remove unnecessary instance_init functions)
  (Eduardo Habkost)
* qdev, qom, and global property code cleanups (Marc-André Lureau)
* PCMachineState field renames (Corey Minyard)
* numa: Match struct to typedef name (Eric Blake)
* hostmem-file: remove object id from pmem error message (Zhang Yi)

# gpg: Signature made Tue 11 Dec 2018 17:58:03 GMT
# gpg:                using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/machine-next-pull-request: (24 commits)
  qom: remove unimplemented class_finalize
  qdev: move qdev_prop_register_global_list() to tests
  accel: register global_props like machine globals
  qom: make user_creatable_complete() specific to UserCreatable
  qom: make interface types abstract
  tests: qdev_prop_check_globals() doesn't return "all_used"
  pc: Use default_machine_opts to set suppress_vmdesc
  spapr: Delete instance_options functions
  spapr: Use default_machine_opts to set suppress_vmdesc
  spapr: Use default_machine_opts to set use_hotplug_event_source
  virt: Eliminate separate instance_init functions
  q35/440fx/arm/spapr: Add QEMU 4.0 machine type
  hostmem: Validate host-nodes before setting bitmap
  numa: Match struct to typedef name
  i386: Rename bools in PCMachineState to end in _enabled
  move ObjectClass to typedefs.h
  memory-device: avoid overflows on very huge devices
  memory-device: use QEMU_IS_ALIGNED
  range: pass const pointer where possible
  Deprecate HMP `cpu-add`
  ...

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
parents ab694df6 37fdb2c5
Loading
Loading
Loading
Loading
+8 −1
Original line number Diff line number Diff line
@@ -34,6 +34,7 @@
#include "qom/object.h"
#include "qemu/error-report.h"
#include "qemu/option.h"
#include "qapi/error.h"

static const TypeInfo accel_type = {
    .name = TYPE_ACCEL,
@@ -121,7 +122,13 @@ void configure_accelerator(MachineState *ms)
void accel_register_compat_props(AccelState *accel)
{
    AccelClass *class = ACCEL_GET_CLASS(accel);
    register_compat_props_array(class->global_props);
    GlobalProperty *prop = class->global_props;

    for (; prop && prop->driver; prop++) {
        /* Any compat_props must never cause error */
        prop->errp = &error_abort;
        qdev_prop_register_global(prop);
    }
}

void accel_setup_post(MachineState *ms)
+4 −10
Original line number Diff line number Diff line
@@ -145,26 +145,20 @@ static void file_memory_backend_set_pmem(Object *o, bool value, Error **errp)
    HostMemoryBackendFile *fb = MEMORY_BACKEND_FILE(o);

    if (host_memory_backend_mr_inited(backend)) {
        char *path = object_get_canonical_path_component(o);

        error_setg(errp, "cannot change property 'pmem' of %s '%s'",
                   object_get_typename(o),
                   path);
        g_free(path);
        error_setg(errp, "cannot change property 'pmem' of %s.",
                   object_get_typename(o));
        return;
    }

#ifndef CONFIG_LIBPMEM
    if (value) {
        Error *local_err = NULL;
        char *path = object_get_canonical_path_component(o);

        error_setg(&local_err,
                   "Lack of libpmem support while setting the 'pmem=on'"
                   " of %s '%s'. We can't ensure data persistence.",
                   object_get_typename(o),
                   path);
        g_free(path);
                   " of %s. We can't ensure data persistence.",
                   object_get_typename(o));
        error_propagate(errp, local_err);
        return;
    }
+13 −4
Original line number Diff line number Diff line
@@ -103,14 +103,23 @@ host_memory_backend_set_host_nodes(Object *obj, Visitor *v, const char *name,
{
#ifdef CONFIG_NUMA
    HostMemoryBackend *backend = MEMORY_BACKEND(obj);
    uint16List *l = NULL;
    uint16List *l, *host_nodes = NULL;

    visit_type_uint16List(v, name, &l, errp);
    visit_type_uint16List(v, name, &host_nodes, errp);

    while (l) {
    for (l = host_nodes; l; l = l->next) {
        if (l->value >= MAX_NODES) {
            error_setg(errp, "Invalid host-nodes value: %d", l->value);
            goto out;
        }
    }

    for (l = host_nodes; l; l = l->next) {
        bitmap_set(backend->host_nodes, l->value, 1);
        l = l->next;
    }

out:
    qapi_free_uint16List(host_nodes);
#else
    error_setg(errp, "NUMA node binding are not supported by this QEMU");
#endif

docs/cpu-hotplug.rst

0 → 100644
+142 −0
Original line number Diff line number Diff line
===================
Virtual CPU hotplug
===================

A complete example of vCPU hotplug (and hot-unplug) using QMP
``device_add`` and ``device_del``.

vCPU hotplug
------------

(1) Launch QEMU as follows (note that the "maxcpus" is mandatory to
    allow vCPU hotplug)::

      $ qemu-system-x86_64 -display none -no-user-config -m 2048 \
          -nodefaults -monitor stdio -machine pc,accel=kvm,usb=off \
          -smp 1,maxcpus=2 -cpu IvyBridge-IBRS \
          -qmp unix:/tmp/qmp-sock,server,nowait

(2) Run 'qmp-shell' (located in the source tree, under: "scripts/qmp/)
    to connect to the just-launched QEMU::

      $> ./qmp-shell -p -v /tmp/qmp-sock
      [...]
      (QEMU)

(3) Find out which CPU types could be plugged, and into which sockets::

      (QEMU) query-hotpluggable-cpus
      {
          "execute": "query-hotpluggable-cpus",
          "arguments": {}
      }
      {
          "return": [
              {
                  "type": "IvyBridge-IBRS-x86_64-cpu",
                  "vcpus-count": 1,
                  "props": {
                      "socket-id": 1,
                      "core-id": 0,
                      "thread-id": 0
                  }
              },
              {
                  "qom-path": "/machine/unattached/device[0]",
                  "type": "IvyBridge-IBRS-x86_64-cpu",
                  "vcpus-count": 1,
                  "props": {
                      "socket-id": 0,
                      "core-id": 0,
                      "thread-id": 0
                  }
              }
          ]
      }
      (QEMU)

(4) The ``query-hotpluggable-cpus`` command returns an object for CPUs
    that are present (containing a "qom-path" member) or which may be
    hot-plugged (no "qom-path" member).  From its output in step (3), we
    can see that ``IvyBridge-IBRS-x86_64-cpu`` is present in socket 0,
    while hot-plugging a CPU into socket 1 requires passing the listed
    properties to QMP ``device_add``:

      (QEMU) device_add id=cpu-2 driver=IvyBridge-IBRS-x86_64-cpu socket-id=1 core-id=0 thread-id=0
      {
          "execute": "device_add",
          "arguments": {
              "socket-id": 1,
              "driver": "IvyBridge-IBRS-x86_64-cpu",
              "id": "cpu-2",
              "core-id": 0,
              "thread-id": 0
          }
      }
      {
          "return": {}
      }
      (QEMU)

(5) Optionally, run QMP `query-cpus-fast` for some details about the
    vCPUs::

      (QEMU) query-cpus-fast
      {
          "execute": "query-cpus-fast",
          "arguments": {}
      }
      {
          "return": [
              {
                  "qom-path": "/machine/unattached/device[0]",
                  "target": "x86_64",
                  "thread-id": 11534,
                  "cpu-index": 0,
                  "props": {
                      "socket-id": 0,
                      "core-id": 0,
                      "thread-id": 0
                  },
                  "arch": "x86"
              },
              {
                  "qom-path": "/machine/peripheral/cpu-2",
                  "target": "x86_64",
                  "thread-id": 12106,
                  "cpu-index": 1,
                  "props": {
                      "socket-id": 1,
                      "core-id": 0,
                      "thread-id": 0
                  },
                  "arch": "x86"
              }
          ]
      }
      (QEMU)

vCPU hot-unplug
---------------

From the 'qmp-shell', invoke the QMP ``device_del`` command::

      (QEMU) device_del id=cpu-2
      {
          "execute": "device_del",
          "arguments": {
              "id": "cpu-2"
          }
      }
      {
          "return": {}
      }
      (QEMU)

.. note::
    vCPU hot-unplug requires guest cooperation; so the ``device_del``
    command above does not guarantee vCPU removal -- it's a "request to
    unplug".  At this point, the guest will get a System Control
    Interupt (SCI) and calls the ACPI handler for the affected vCPU
    device.  Then the guest kernel will bring the vCPU offline and tell
    QEMU to unplug it.
+4 −2
Original line number Diff line number Diff line
@@ -1849,14 +1849,16 @@ ETEXI
        .name       = "cpu-add",
        .args_type  = "id:i",
        .params     = "id",
        .help       = "add cpu",
        .help       = "add cpu (deprecated, use device_add instead)",
        .cmd        = hmp_cpu_add,
    },

STEXI
@item cpu-add @var{id}
@findex cpu-add
Add CPU with id @var{id}
Add CPU with id @var{id}.  This command is deprecated, please
+use @code{device_add} instead. For details, refer to
'docs/cpu-hotplug.rst'.
ETEXI

    {
Loading