1. 13 7月, 2018 1 次提交
  2. 04 7月, 2018 3 次提交
    • M
      qmp: Redo how the client requests out-of-band execution · 00ecec15
      Markus Armbruster 提交于
      Commit cf869d53 "qmp: support out-of-band (oob) execution" added a
      general mechanism for command-independent arguments just for an
      out-of-band flag:
      
          The "control" key is introduced to store this extra flag.  "control"
          field is used to store arguments that are shared by all the commands,
          rather than command specific arguments.  Let "run-oob" be the first.
      
      However, it failed to reject unknown members of "control".  For
      instance, in QMP command
      
          {"execute": "query-name", "id": 42, "control": {"crap": true}}
      
      "crap" gets silently ignored.
      
      Instead of fixing this, revert the general "control" mechanism
      (because YAGNI), and do it the way I initially proposed, with key
      "exec-oob".  Simpler code, simpler interface.
      
      An out-of-band command
      
          {"execute": "migrate-pause", "id": 42, "control": {"run-oob": true}}
      
      becomes
      
          {"exec-oob": "migrate-pause", "id": 42}
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20180703085358.13941-13-armbru@redhat.com>
      [Commit message typo fixed]
      00ecec15
    • M
      qmp: Make "id" optional again even in "oob" monitors · 80cd93bd
      Markus Armbruster 提交于
      Commit cf869d53 "qmp: support out-of-band (oob) execution" made
      "id" mandatory for all commands when the client accepted capability
      "oob".  This is rather onerous when you play with QMP by hand, and
      unnecessarily so: only out-of-band commands need an ID for reliable
      matching of response to command.
      
      Revert that part of commit cf869d53 for now, but have documentation
      advise on the need to use "id" with out-of-band commands.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180703085358.13941-8-armbru@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      80cd93bd
    • M
      docs/interop/qmp: Improve OOB documentation · 71696cc6
      Markus Armbruster 提交于
      OOB documentation is spread over qmp-spec.txt sections 2.2.1
      Capabilities and 2.3 Issuing Commands.  The amount of detail is a bit
      distracting there.  Move the meat of the matter to new section 2.3.1
      Out of band execution.
      
      Throw in a few other improvements while there:
      
      * 2.2 Server Greeting: Drop advice to search entire capabilities
        array; should be obvious.
      
      * 3. QMP Examples
      
        - 3.1 Server Greeting: Update greeting to the one we expect for the
          release.  Now shows capability "oob".  Update qmp-intro.txt
          likewise.
      
        - 3.2 Capabilities negotiation: Show client accepting capability
          "oob".
      
        - 3.7 Out-of-band execution: New.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <20180703085358.13941-4-armbru@redhat.com>
      [Whitespace tidied up]
      71696cc6
  3. 03 7月, 2018 1 次提交
  4. 21 6月, 2018 1 次提交
  5. 01 6月, 2018 1 次提交
    • L
      docs/interop: add "firmware.json" · 3a0adfc9
      Laszlo Ersek 提交于
      Add a schema that describes the different uses and properties of virtual
      machine firmware.
      
      Each firmware executable installed on a host system should come with at
      least one JSON file that conforms to this schema. Each file informs the
      management applications about
      - the firmware's properties and one possible use case / feature set,
      - configuration bits that are required to run the firmware binary.
      
      In addition, define rules for management apps for picking the highest
      priority firmware JSON file when multiple such files match the search
      criteria.
      
      Cc: "Daniel P. Berrange" <berrange@redhat.com>
      Cc: David Gibson <dgibson@redhat.com>
      Cc: Eric Blake <eblake@redhat.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Kashyap Chamarthy <kchamart@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Thomas Huth <thuth@redhat.com>
      Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
      Message-Id: <20180509152608.9343-1-lersek@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3a0adfc9
  6. 25 5月, 2018 2 次提交
  7. 15 5月, 2018 1 次提交
  8. 09 4月, 2018 1 次提交
  9. 20 3月, 2018 6 次提交
  10. 03 3月, 2018 3 次提交
  11. 02 3月, 2018 1 次提交
  12. 22 1月, 2018 1 次提交
  13. 19 1月, 2018 2 次提交
  14. 22 12月, 2017 2 次提交
  15. 27 11月, 2017 1 次提交
    • K
      QAPI & interop: Clarify events emitted by 'block-job-cancel' · c117bb14
      Kashyap Chamarthy 提交于
      When you cancel an in-progress 'mirror' job (or "active `block-commit`")
      with QMP `block-job-cancel`, it emits the event: BLOCK_JOB_CANCELLED.
      However, when `block-job-cancel` is issued *after* `drive-mirror` has
      indicated (via the event BLOCK_JOB_READY) that the source and
      destination have reached synchronization:
      
          [...] # Snip `drive-mirror` invocation & outputs
          {
            "execute":"block-job-cancel",
            "arguments":{
              "device":"virtio0"
            }
          }
      
          {"return": {}}
      
      It (`block-job-cancel`) will counterintuitively emit the event
      'BLOCK_JOB_COMPLETED':
      
          {
            "timestamp":{
              "seconds":1510678024,
              "microseconds":526240
            },
            "event":"BLOCK_JOB_COMPLETED",
            "data":{
              "device":"virtio0",
              "len":41126400,
              "offset":41126400,
              "speed":0,
              "type":"mirror"
            }
          }
      
      But this is expected behaviour, where the _COMPLETED event indicates
      that synchronization has successfully ended (and the destination now has
      a point-in-time copy, which is at the time of cancel).
      
      So add a small note to this effect in 'block-core.json'.  While at it,
      also update the "Live disk synchronization -- drive-mirror and
      blockdev-mirror" section in 'live-block-operations.rst'.
      
      (Thanks: Max Reitz for reminding me of this caveat on IRC.)
      Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c117bb14
  16. 21 11月, 2017 2 次提交
    • S
      Use HTTPS for qemu.org and other domains · 70b7fba9
      Stefan Hajnoczi 提交于
      qemu.org enabled HTTPS in 2017 and it should be used instead of HTTP.
      There are also URLs to json.org, openvpn.net, and other domains that
      support HTTPS.
      
      This patch updates the qemu.org domains everywhere and also third-party
      domains that I have checked.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Message-id: 20171121120435.28728-3-stefanha@redhat.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      70b7fba9
    • S
      Use qemu.org domain name · 1b3bbc68
      Stefan Hajnoczi 提交于
      The owner of qemu.org has delegated authority to modify DNS records to
      the QEMU Project.  This has allowed us to use the domain name without
      worries about IP address changes or technical issues disrupting service.
      The issues described in commit 85938981
      ("Use qemu-project.org domain name") have therefore been mitigated.
      
      This patch switches back to consistently using qemu.org instead of
      qemu-project.org in documentation, version.rc, and the Windows installer
      script.
      
      The git submodules and SeaBIOS still use qemu-project.org for the time
      being.  This will be fixed in the QEMU 2.12 release cycle.
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Message-id: 20171121120435.28728-2-stefanha@redhat.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      1b3bbc68
  17. 23 9月, 2017 1 次提交
    • P
      scsi: build qemu-pr-helper · b855f8d1
      Paolo Bonzini 提交于
      Introduce a privileged helper to run persistent reservation commands.
      This lets virtual machines send persistent reservations without using
      CAP_SYS_RAWIO or out-of-tree patches.  The helper uses Unix permissions
      and SCM_RIGHTS to restrict access to processes that can access its socket
      and prove that they have an open file descriptor for a raw SCSI device.
      
      The next patch will also correct the usage of persistent reservations
      with multipath devices.
      
      It would also be possible to support for Linux's IOC_PR_* ioctls in
      the future, to support NVMe devices.  For now, however, only SCSI is
      supported.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b855f8d1
  18. 02 8月, 2017 1 次提交
  19. 18 7月, 2017 2 次提交
    • K
      live-block-ops.txt: Rename, rewrite, and improve it · 8508eee7
      Kashyap Chamarthy 提交于
      This patch documents (including their QMP invocations) all the four
      major kinds of live block operations:
      
        - `block-stream`
        - `block-commit`
        - `drive-mirror` (& `blockdev-mirror`)
        - `drive-backup` (& `blockdev-backup`)
      
      Things considered while writing this document:
      
        - Use reStructuredText as markup language (with the goal of generating
          the HTML output using the Sphinx Documentation Generator).  It is
          gentler on the eye, and can be trivially converted to different
          formats.  (Another reason: upstream QEMU is considering to switch to
          Sphinx, which uses reStructuredText as its markup language.)
      
        - Raw QMP JSON output vs. 'qmp-shell'.  I debated with myself whether
          to only show raw QMP JSON output (as that is the canonical
          representation), or use 'qmp-shell', which takes key-value pairs.  I
          settled on the approach of: for the first occurrence of a command,
          use raw JSON; for subsequent occurrences, use 'qmp-shell', with an
          occasional exception.
      
        - Usage of `-blockdev` command-line.
      
        - Usage of 'node-name' vs. file path to refer to disks.  While we have
          `blockdev-{mirror, backup}` as 'node-name'-alternatives for
          `drive-{mirror, backup}`, the `block-commit` command still operates
          on file names for parameters 'base' and 'top'.  So I added a caveat
          at the beginning to that effect.
      
          Refer this related thread that I started (where I learnt
          `block-stream` was recently reworked to accept 'node-name' for 'top'
          and 'base' parameters):
          https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg06466.html
          "[RFC] Making 'block-stream', and 'block-commit' accept node-name"
      
      All commands showed in this document were tested while documenting.
      
      Thanks: Eric Blake for the section: "A note on points-in-time vs file
      names".  This useful bit was originally articulated by Eric in his
      KVMForum 2015 presentation, so I included that specific bit in this
      document.
      Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 20170717105205.32639-3-kchamart@redhat.com
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      8508eee7
    • K
      bitmaps.md: Convert to rST; move it into 'interop' dir · 7746cf8a
      Kashyap Chamarthy 提交于
      This is part of the on-going effort to convert QEMU upstream
      documentation syntax to reStructuredText (rST).
      
      The conversion to rST was done using:
      
          $ pandoc -f markdown -t rst bitmaps.md -o bitmaps.rst
      
      Then, make a couple of small syntactical adjustments.  While at it,
      reword a statement to avoid ambiguity.  Addressing the feedback from
      this thread:
      
          https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg05428.htmlSigned-off-by: NKashyap Chamarthy <kchamart@redhat.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 20170717105205.32639-2-kchamart@redhat.com
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      7746cf8a
  20. 11 7月, 2017 3 次提交
  21. 15 6月, 2017 1 次提交