Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Dec 20, 2017
  3. Dec 19, 2017
  5. Nov 27, 2017
    • Kashyap Chamarthy's avatar
      QAPI & interop: Clarify events emitted by 'block-job-cancel' · c117bb14
      Kashyap Chamarthy authored 
      
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: default avatarKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      c117bb14
    • Fam Zheng's avatar
      docs: Add image locking subsection · b1d1cb27
      Fam Zheng authored 
      
This documents the image locking feature and explains when and how
related options can be used.

Signed-off-by: default avatarFam Zheng <famz@redhat.com>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      b1d1cb27
  7. Nov 21, 2017
    • Stefan Hajnoczi's avatar
      Use HTTPS for qemu.org and other domains · 70b7fba9
      Stefan Hajnoczi authored 
      
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: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-id: 20171121120435.28728-3-stefanha@redhat.com
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      70b7fba9
    • Stefan Hajnoczi's avatar
      Use qemu.org domain name · 1b3bbc68
      Stefan Hajnoczi authored 
      
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: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-id: 20171121120435.28728-2-stefanha@redhat.com
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      1b3bbc68
  9. Nov 15, 2017
  11. Nov 05, 2017
  13. Oct 16, 2017
  15. Oct 15, 2017
  17. Oct 13, 2017
  19. Sep 27, 2017
  21. Sep 26, 2017
  23. Sep 22, 2017
    • Paolo Bonzini's avatar
      scsi: add multipath support to qemu-pr-helper · fe8fc5ae
      Paolo Bonzini authored 
      
Proper support of persistent reservation for multipath devices requires
communication with the multipath daemon, so that the reservation is
registered and applied when a path comes up.  The device mapper
utilities provide a library to do so; this patch makes qemu-pr-helper.c
detect multipath devices and, when one is found, delegate the operation
to libmpathpersist.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fe8fc5ae
    • Paolo Bonzini's avatar
      scsi: build qemu-pr-helper · b855f8d1
      Paolo Bonzini authored 
      
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: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b855f8d1
  25. Sep 21, 2017
    • Paolo Bonzini's avatar
      scsi, file-posix: add support for persistent reservation management · 7c9e5276
      Paolo Bonzini authored 
      
It is a common requirement for virtual machine to send persistent
reservations, but this currently requires either running QEMU with
CAP_SYS_RAWIO, or using out-of-tree patches that let an unprivileged
QEMU bypass Linux's filter on SG_IO commands.

As an alternative mechanism, the next patches will introduce a
privileged helper to run persistent reservation commands without
expanding QEMU's attack surface unnecessarily.

The helper is invoked through a "pr-manager" QOM object, to which
file-posix.c passes SG_IO requests for PERSISTENT RESERVE OUT and
PERSISTENT RESERVE IN commands.  For example:

  $ qemu-system-x86_64
      -device virtio-scsi \
      -object pr-manager-helper,id=helper0,path=/var/run/qemu-pr-helper.sock
      -drive if=none,id=hd,driver=raw,file.filename=/dev/sdb,file.pr-manager=helper0
      -device scsi-block,drive=hd

or:

  $ qemu-system-x86_64
      -device virtio-scsi \
      -object pr-manager-helper,id=helper0,path=/var/run/qemu-pr-helper.sock
      -blockdev node-name=hd,driver=raw,file.driver=host_device,file.filename=/dev/sdb,file.pr-manager=helper0
      -device scsi-block,drive=hd

Multiple pr-manager implementations are conceivable and possible, though
only one is implemented right now.  For example, a pr-manager could:

- talk directly to the multipath daemon from a privileged QEMU
  (i.e. QEMU links to libmpathpersist); this makes reservation work
  properly with multipath, but still requires CAP_SYS_RAWIO

- use the Linux IOC_PR_* ioctls (they require CAP_SYS_ADMIN though)

- more interestingly, implement reservations directly in QEMU
  through file system locks or a shared database (e.g. sqlite)

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      7c9e5276
    • Paolo Bonzini's avatar
      memory: avoid "resurrection" of dead FlatViews · 447b0d0b
      Paolo Bonzini authored 
      
It's possible for address_space_get_flatview() as it currently stands
to cause a use-after-free for the returned FlatView, if the reference
count is incremented after the FlatView has been replaced by a writer:

   thread 1             thread 2             RCU thread
  -------------------------------------------------------------
   rcu_read_lock
   read as->current_map
                        set as->current_map
                        flatview_unref
                           '--> call_rcu
   flatview_ref
     [ref=1]
   rcu_read_unlock
                                             flatview_destroy
   <badness>

Since FlatViews are not updated very often, we can just detect the
situation using a new atomic op atomic_fetch_inc_nonzero, similar to
Linux's atomic_inc_not_zero, which performs the refcount increment only if
it hasn't already hit zero.  This is similar to Linux commit de09a9771a53
("CRED: Fix get_task_cred() and task_state() to not resurrect dead
credentials", 2010-07-29).

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      447b0d0b
    • Paolo Bonzini's avatar
      atomic: update documentation · db81b995
      Paolo Bonzini authored 
      
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      db81b995
  27. Sep 19, 2017
  29. Sep 08, 2017
  31. Sep 04, 2017
  33. Aug 01, 2017
    • Felipe Franciosi's avatar
      vhost-user: fix legacy cross-endian configurations · 5df04f17
      Felipe Franciosi authored 
      
Currently, vhost-user does not implement any means for notifying the
backend about guest endianess. This commit introduces a new message
called VHOST_USER_SET_VRING_ENDIAN which is analogous to the ioctl()
called VHOST_SET_VRING_ENDIAN used for kernel vhost backends. Such
message is necessary for backends supporting legacy (pre-1.0) virtio
devices running in big-endian guests.

Signed-off-by: default avatarFelipe Franciosi <felipe@nutanix.com>
Signed-off-by: default avatarMike Cui <cui@nutanix.com>
      5df04f17
    • Stefan Hajnoczi's avatar
      trace: add trace_event_get_state_backends() · d87aa138
      Stefan Hajnoczi authored 
      
Code that checks dstate is unaware of SystemTap and LTTng UST dstate, so
the following trace event will not fire when solely enabled by SystemTap
or LTTng UST:

  if (trace_event_get_state(TRACE_MY_EVENT)) {
      str = g_strdup_printf("Expensive string to generate ...",
                            ...);
      trace_my_event(str);
      g_free(str);
  }

Add trace_event_get_state_backends() to fetch backend dstate.  Those
backends that use QEMU dstate fetch it as part of
generate_h_backend_dstate().

Update existing trace_event_get_state() callers to use
trace_event_get_state_backends() instead.

Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
Message-id: 20170731140718.22010-3-stefanha@redhat.com
Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      d87aa138
  35. Jul 31, 2017
  37. Jul 24, 2017
  39. Jul 18, 2017
    • Kashyap Chamarthy's avatar
      live-block-ops.txt: Rename, rewrite, and improve it · 8508eee7
      Kashyap Chamarthy authored 
      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: default avatarKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Message-id: 20170717105205.32639-3-kchamart@redhat.com
Signed-off-by: default avatarJeff Cody <jcody@redhat.com>
      8508eee7
    • Kashyap Chamarthy's avatar
      bitmaps.md: Convert to rST; move it into 'interop' dir · 7746cf8a
      Kashyap Chamarthy authored 
      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.html



Signed-off-by: default avatarKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
Reviewed-by: default avatarEric Blake <eblake@redhat.com>
Message-id: 20170717105205.32639-2-kchamart@redhat.com
Signed-off-by: default avatarJeff Cody <jcody@redhat.com>
      7746cf8a
  41. Jul 17, 2017
  43. Jul 14, 2017
  45. Jul 11, 2017