1. 16 7月, 2018 1 次提交
  2. 04 7月, 2018 3 次提交
    • M
      qmp: Get rid of x-oob-test command · 97ca0712
      Markus Armbruster 提交于
      tests/qmp-test tests an out-of-band command overtaking a slow in-band
      command.  To do that, it needs:
      
      1. An in-band command that *reliably* takes long enough to be
         overtaken.
      
      2. An out-of-band command to do the overtaking.
      
      3. To avoid delays, a way to make the in-band command complete quickly
         after it was overtaken.
      
      To satisfy these needs, commit 469638f9 provides the rather
      peculiar oob-capable QMP command x-oob-test:
      
      * With "lock": true, it waits for a global semaphore.
      
      * With "lock": false, it signals the global semaphore.
      
      To satisfy 1., the test runs x-oob-test in-band with "lock": true.
      To satisfy 2. and 3., it runs x-oob-test out-of-band with "lock": false.
      
      Note that waiting for a semaphore violates the rules for oob-capable
      commands.  Running x-oob-test with "lock": true hangs the monitor
      until you run x-oob-test with "lock": false on another monitor (which
      you might not have set up).
      
      Having an externally visible QMP command that may hang the monitor is
      not nice.  Let's apply a little more ingenuity to the problem.  Idea:
      have an existing command block on reading a FIFO special file, unblock
      it by opening the FIFO for writing.
      
      For 1., use
      
          {"execute": "blockdev-add",  "id": ID1,
           "arguments": {
              "driver": "blkdebug", "node-name": ID1, "config": FIFO,
              "image": { "driver": "null-co"}}}
      
      where ID1 is an arbitrary string, and FIFO is the name of the FIFO.
      
      For 2., use
      
          {"execute": "migrate-pause", "id": ID2, "control": {"run-oob": true}}
      
      where ID2 is a different arbitrary string.  Since there's no migration
      to pause, the command will fail, but that's fine; instant failure is
      still a test of out-of-band responses overtaking in-band commands.
      
      For 3., open FIFO for writing.
      
      Drop QMP command x-oob-test.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20180703085358.13941-6-armbru@redhat.com>
      [Error checking tweaked]
      97ca0712
    • M
      qapi: add conditions to SPICE type/commands/events on the schema · 514337c1
      Marc-André Lureau 提交于
      Add #if defined(CONFIG_SPICE) in generated code, and adjust the
      qmp/hmp code accordingly.
      
      query-qmp-schema no longer reports the command/events etc as
      available when disabled at compile time.
      
      Commands made conditional:
      
      * query-spice
      
        Before the patch, the command for !CONFIG_SPICE is unregistered. It
        will fail with the same error.
      
      Events made conditional:
      
      * SPICE_CONNECTED, SPICE_INITIALIZED, SPICE_DISCONNECTED,
        SPICE_MIGRATE_COMPLETED
      
      Add TODO for conditional SPICE chardevs, delayed until the supports
      for conditional members lands.
      
      No HMP change, the code was already conditional.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180703155648.11933-15-marcandre.lureau@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      514337c1
    • M
      qapi: add conditions to VNC type/commands/events on the schema · 05eb4a25
      Marc-André Lureau 提交于
      Add #if defined(CONFIG_VNC) in generated code, and adjust the
      qmp/hmp code accordingly.
      
      query-qmp-schema no longer reports the command/events etc as
      available when disabled at compile.
      
      Commands made conditional:
      
      * query-vnc, query-vnc-servers, change-vnc-password
      
        Before the patch, the commands for !CONFIG_VNC are stubs that fail
        like this:
      
          {"error": {"class": "GenericError",
                     "desc": "The feature 'vnc' is not enabled"}}
      
        Afterwards, they fail like this:
      
          {"error": {"class": "CommandNotFound",
                     "desc": "The command FOO has not been found"}}
      
        I call that an improvement, because it lets clients distinguish
        between command unavailable (class CommandNotFound) and command failed
        (class GenericError).
      
      Events made conditional:
      
      * VNC_CONNECTED, VNC_INITIALIZED, VNC_DISCONNECTED
      
      HMP change:
      
      * info vnc
      
        Will return "unknown command: 'info vnc'" when VNC is compiled
        out (same as error for spice when --disable-spice)
      
      Occurrences of VNC (case insensitive) in the schema that aren't
      covered by this change:
      
      * add_client
      
        Command has other uses, including "socket bases character devices".
        These are unconditional as far as I can tell.
      
      * set_password, expire_password
      
        In theory, these commands could be used for managing any service's
        password.  In practice, they're used for VNC and SPICE services.
        They're documented for "remote display session" / "remote display
        server".
      
        The service is selected by argument @protocol.  The code special-cases
        protocol-specific argument checking, then calls a protocol-specific
        function to do the work.  If it fails, the command fails with "Could
        not set password".  It does when the service isn't compiled in (it's a
        stub then).
      
        We could make these commands conditional on the conjunction of all
        services [currently: defined(CONFIG_VNC) || defined(CONFIG_SPICE)],
        but I doubt it's worthwhile.
      
      * change
      
        Command has other uses, namely changing media.
        This patch inlines a stub; no functional change.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180703155648.11933-14-marcandre.lureau@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      05eb4a25
  3. 31 5月, 2018 1 次提交
    • I
      cli: add --preconfig option · 047f7038
      Igor Mammedov 提交于
      This option allows pausing QEMU in the new RUN_STATE_PRECONFIG state,
      allowing the configuration of QEMU from QMP before the machine jumps
      into board initialization code of machine_run_board_init()
      
      The intent is to allow management to query machine state and additionally
      configure it using previous query results within one QEMU instance
      (i.e. eliminate the need to start QEMU twice, 1st to query board specific
      parameters and 2nd for actual VM start using query results for
      additional parameters).
      
      The new option complements -S option and could be used with or without
      it. The difference is that -S pauses QEMU when the machine is completely
      initialized with all devices wired up and ready to execute guest code
      (QEMU needs only to unpause VCPUs to let guest execute its code),
      while the "preconfig" option pauses QEMU early before board specific init
      callback (machine_run_board_init) is executed and allows the configuration
      of machine parameters which will be used by board init code.
      
      When early introspection/configuration is done, command 'exit-preconfig'
      should be used to exit RUN_STATE_PRECONFIG and transition to the next
      requested state (i.e. if -S is used then QEMU will pause the second
      time when board/device initialization is completed or start guest
      execution if -S isn't provided on CLI)
      
      PS:
      Initially 'preconfig' is planned to be used for configuring numa
      topology depending on board specified possible cpus layout.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1526059483-42847-1-git-send-email-imammedo@redhat.com>
      [ehabkost: Changed "since 2.13" to "since 3.0"]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      047f7038
  4. 07 5月, 2018 1 次提交
    • D
      pc-dimm: factor out MemoryDevice interface · 2cc0e2e8
      David Hildenbrand 提交于
      On the qmp level, we already have the concept of memory devices:
          "query-memory-devices"
      Right now, we only support NVDIMM and PCDIMM.
      
      We want to map other devices later into the address space of the guest.
      Such device could e.g. be virtio devices. These devices will have a
      guest memory range assigned but won't be exposed via e.g. ACPI. We want
      to make them look like memory device, but not glued to pc-dimm.
      
      Especially, it will not always be possible to have TYPE_PC_DIMM as a parent
      class (e.g. virtio devices). Let's use an interface instead. As a first
      part, convert handling of
      - qmp_pc_dimm_device_list
      - get_plugged_memory_size
      to our new model. plug/unplug stuff etc. will follow later.
      
      A memory device will have to provide the following functions:
      - get_addr(): Necessary, as the property "addr" can e.g. not be used for
                    virtio devices (already defined).
      - get_plugged_size(): The amount this device offers to the guest as of
                            now.
      - get_region_size(): Because this can later on be bigger than the
                           plugged size.
      - fill_device_info(): Fill MemoryDeviceInfo, e.g. for qmp.
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Message-Id: <20180423165126.15441-2-david@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      2cc0e2e8
  5. 04 5月, 2018 1 次提交
  6. 20 3月, 2018 3 次提交
  7. 06 3月, 2018 2 次提交
    • A
      qmp: Add qom-list-properties to list QOM object properties · 961c47bb
      Alexey Kardashevskiy 提交于
      There is already 'device-list-properties' which does most of the job,
      however it does not handle everything returned by qom-list-types such
      as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE.
      It does not handle abstract classes either.
      
      This adds a new qom-list-properties command which prints properties
      of a specific class and its instance. It is pretty much a simplified copy
      of the device-list-properties handler.
      
      Since it creates an object instance, device properties should appear
      in the output as they are copied to QOM properties at the instance_init
      hook.
      
      This adds a object_class_property_iter_init() helper to allow class
      properties enumeration uses it in the new QMP command to allow properties
      listing for abstract classes.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Message-Id: <20180301130939.15875-3-aik@ozlabs.ru>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      961c47bb
    • A
      qmp: Merge ObjectPropertyInfo and DevicePropertyInfo · 35f63767
      Alexey Kardashevskiy 提交于
      ObjectPropertyInfo is more generic and only missing @description.
      This adds a description to ObjectPropertyInfo and removes
      DevicePropertyInfo so the resulting ObjectPropertyInfo can be used
      elsewhere.
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Message-Id: <20180301130939.15875-2-aik@ozlabs.ru>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      35f63767
  8. 03 3月, 2018 2 次提交
  9. 09 2月, 2018 4 次提交
  10. 21 12月, 2017 1 次提交
    • D
      qmp: remove qmp_cpu · 49ccefde
      Daniel Henrique Barboza 提交于
      'qmp_cpu' was implemented in commit 755f1968 ("qapi: Convert the cpu
      command") as a functional no-op, a QMP call that does nothing and
      return success. The idea, apparently, was to provide a counterpart
      for the HMP 'hmp_cpu' command, introduced in the same commit.
      
      After 6 years of its creation, qmp_cpu remains a functional no-op
      that does nothing, having no value for any caller/user. A proposal
      was sent to implement qmp_cpu like hmp_cpu works, but it was denied
      [1]. The reason is that QMP must be as stateless as possible and a
      function that changes its state (the current CPU monitor in the case
      of qmp_cpu) goes against it. Any QMP command that needs a specific
      monitor CPU setup must provide it in its arguments, instead of relying
      in the current QMP monitor state.
      
      After discussions that happened in [2] it was decided that a command
      that does nothing since its birth, no one uses for anything and will
      not be implemented, should be deprecated and erased. Given that we will
      *not* provide any replacement for qmp_cpu and we believe that there
      is no user relying on it, there is no point in adding a deprecation
      delay for it.
      
      So, this patch nukes qmp_cpu from QEMU code, removing both its blank
      implementation in qmp.c and its doc in qapi-schema.json.
      
      [1] https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg02283.html
      [2] https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg03696.htmlSigned-off-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
      CC: Markus Armbruster <armbru@redhat.com>
      CC: Eric Blake <eblake@redhat.com>
      CC: Daniel P. Berrange <berrange@redhat.com>
      Message-Id: <20171220102304.8288-1-danielhb@linux.vnet.ibm.com>
      Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      49ccefde
  11. 14 9月, 2017 1 次提交
  12. 18 7月, 2017 2 次提交
  13. 14 7月, 2017 2 次提交
  14. 11 7月, 2017 1 次提交
  15. 02 6月, 2017 1 次提交
  16. 23 5月, 2017 1 次提交
    • E
      shutdown: Add source information to SHUTDOWN and RESET · cf83f140
      Eric Blake 提交于
      Time to wire up all the call sites that request a shutdown or
      reset to use the enum added in the previous patch.
      
      It would have been less churn to keep the common case with no
      arguments as meaning guest-triggered, and only modified the
      host-triggered code paths, via a wrapper function, but then we'd
      still have to audit that I didn't miss any host-triggered spots;
      changing the signature forces us to double-check that I correctly
      categorized all callers.
      
      Since command line options can change whether a guest reset request
      causes an actual reset vs. a shutdown, it's easy to also add the
      information to reset requests.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Acked-by: David Gibson <david@gibson.dropbear.id.au> [ppc parts]
      Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> [SPARC part]
      Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x parts]
      Message-Id: <20170515214114.15442-5-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      cf83f140
  17. 11 5月, 2017 2 次提交
    • K
      block: New BdrvChildRole.activate() for blk_resume_after_migration() · 4417ab7a
      Kevin Wolf 提交于
      Instead of manually calling blk_resume_after_migration() in migration
      code after doing bdrv_invalidate_cache_all(), integrate the BlockBackend
      activation with cache invalidation into a single function. This is
      achieved with a new callback in BdrvChildRole that is called by
      bdrv_invalidate_cache_all().
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      4417ab7a
    • K
      migration: Unify block node activation error handling · ace21a58
      Kevin Wolf 提交于
      Migration code activates all block driver nodes on the destination when
      the migration completes. It does so by calling
      bdrv_invalidate_cache_all() and blk_resume_after_migration(). There is
      one code path for precopy and one for postcopy migration, resulting in
      four function calls, which used to have three different failure modes.
      
      This patch unifies the behaviour so that failure to activate all block
      nodes is non-fatal, but the error message is logged and the VM isn't
      automatically started. 'cont' will retry activating the block nodes.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      ace21a58
  18. 21 4月, 2017 1 次提交
  19. 07 4月, 2017 1 次提交
    • K
      block: Ignore guest dev permissions during incoming migration · d35ff5e6
      Kevin Wolf 提交于
      Usually guest devices don't like other writers to the same image, so
      they use blk_set_perm() to prevent this from happening. In the migration
      phase before the VM is actually running, though, they don't have a
      problem with writes to the image. On the other hand, storage migration
      needs to be able to write to the image in this phase, so the restrictive
      blk_set_perm() call of qdev devices breaks it.
      
      This patch flags all BlockBackends with a qdev device as
      blk->disable_perm during incoming migration, which means that the
      requested permissions are stored in the BlockBackend, but not actually
      applied to its root node yet.
      
      Once migration has finished and the VM should be resumed, the
      permissions are applied. If they cannot be applied (e.g. because the NBD
      server used for block migration hasn't been shut down), resuming the VM
      fails.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Tested-by: NKashyap Chamarthy <kchamart@redhat.com>
      d35ff5e6
  20. 05 3月, 2017 1 次提交
  21. 01 2月, 2017 1 次提交
  22. 28 1月, 2017 1 次提交
  23. 27 1月, 2017 1 次提交
  24. 28 10月, 2016 1 次提交
  25. 25 10月, 2016 2 次提交
  26. 06 10月, 2016 1 次提交
  27. 23 9月, 2016 1 次提交