[Qemu-commits] [qemu/qemu] e4603f: qcow2: Fix header update with overridden backing f...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: e4603fe139e2161464d7e75faa3a650e31f057fc
      
https://github.com/qemu/qemu/commit/e4603fe139e2161464d7e75faa3a650e31f057fc
  Author: Kevin Wolf <address@hidden>
  Date:   2015-04-08 (Wed, 08 Apr 2015)

  Changed paths:
    M block/qcow2.c
    M block/qcow2.h
    A tests/qemu-iotests/130
    A tests/qemu-iotests/130.out
    M tests/qemu-iotests/group

  Log Message:
  -----------
  qcow2: Fix header update with overridden backing file

In recent qemu versions, it is possible to override the backing file
name and format that is stored in the image file with values given at
runtime. In such cases, the temporary override could end up in the
image header if the qcow2 header was updated, while obviously correct
behaviour would be to leave the on-disk backing file path/format
unchanged.

Fix this and add a test case for it.

Reported-by: Michael Tokarev <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: 2a6cdd6d35158bc7a6aacd92b5b0302f28ec480e
      
https://github.com/qemu/qemu/commit/2a6cdd6d35158bc7a6aacd92b5b0302f28ec480e
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-04-08 (Wed, 08 Apr 2015)

  Changed paths:
    M hw/block/dataplane/virtio-blk.c
    M hw/block/virtio-blk.c
    M include/hw/virtio/virtio-blk.h

  Log Message:
  -----------
  virtio-blk: correctly dirty guest memory

After qemu_iovec_destroy, the QEMUIOVector's size is zeroed and
the zero size ultimately is used to compute virtqueue_push's len
argument.  Therefore, reads from virtio-blk devices did not
migrate their results correctly.  (Writes were okay).

Save the size in virtio_blk_handle_request, and use it when the request
is completed.

Based on a patch by Wen Congyang.

Signed-off-by: Wen Congyang <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Tested-by: Li Zhijian <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: e8d3b1a25f284cdf9705b7cf0412281cc9ee3a36
      
https://github.com/qemu/qemu/commit/e8d3b1a25f284cdf9705b7cf0412281cc9ee3a36
  Author: Paolo Bonzini <address@hidden>
  Date:   2015-04-09 (Thu, 09 Apr 2015)

  Changed paths:
    M async.c

  Log Message:
  -----------
  aio: strengthen memory barriers for bottom half scheduling

There are two problems with memory barriers in async.c.  The fix is
to use atomic_xchg in order to achieve sequential consistency between
the scheduling of a bottom half and the corresponding execution.

First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does
not execute a memory barrier to order any writes needed by the callback
before the read of bh->scheduled.  If the other side sees req->state as
THREAD_ACTIVE, the callback is not invoked and you get deadlock.

Second, the memory barrier in aio_bh_poll is too weak.  Without this
patch, it is possible that bh->scheduled = 0 is not "published" until
after the callback has returned.  Another thread wants to schedule the
bottom half, but it sees bh->scheduled = 1 and does nothing.  This causes
a lost wakeup.  The memory barrier should have been changed to smp_mb()
in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition,
2014-06-03) together with qemu_bh_schedule()'s.  Guess who reviewed
that patch?

Both of these involve a store and a load, so they are reproducible on
x86_64 as well.  It is however much easier on aarch64, where the
libguestfs test suite triggers the bug fairly easily.  Even there the
failure can go away or appear depending on compiler optimization level,
tracing options, or even kernel debugging options.

Paul Leveille however reported how to trigger the problem within 15
minutes on x86_64 as well.  His (untested) recipe, reproduced here
for reference, is the following:

   1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem.

   2) Use “cache=directsync” rather than the default of
   “cache=none” to make it happen easier.

   3) Use a server with a write-back RAID controller to allow for rapid
   IO rates.

   4) Run a random-access load that (mostly) writes chunks to various
   files on the virtual block device.

      a. I use ‘diskload.exe c:25’, a Microsoft HCT load
   generator, on Windows VMs.

      b. Iometer can probably be configured to generate a similar load.

   5) Run multiple VMs in parallel, against the same storage device,
   to shake the failure out sooner.

   6) IvyBridge and Haswell processors for certain; not sure about others.

A similar patch survived over 12 hours of testing, where an unpatched
QEMU would fail within 15 minutes.

This bug is, most likely, also the cause of failures in the libguestfs
testsuite on AArch64.

Thanks to Laszlo Ersek for initially reporting this bug, to Stefan
Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to
Paul for providing test input and a prototype patch.

Reported-by: Laszlo Ersek <address@hidden>
Reported-by: Paul Leveille <address@hidden>
Reported-by: John Snow <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Suggested-by: Paul Leveille <address@hidden>
Suggested-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: 05b685fbabb7fdcab72cb42b27db916fd74b2265
      
https://github.com/qemu/qemu/commit/05b685fbabb7fdcab72cb42b27db916fd74b2265
  Author: Peter Lieven <address@hidden>
  Date:   2015-04-09 (Thu, 09 Apr 2015)

  Changed paths:
    M block/iscsi.c

  Log Message:
  -----------
  block/iscsi: handle zero events from iscsi_which_events

newer libiscsi versions may return zero events from iscsi_which_events.

In this case iscsi_service will return immediately without any progress.
To avoid busy waiting for iscsi_which_events to change we deregister all
read and write handlers in this case and schedule a timer to periodically
check iscsi_which_events for changed events.

Next libiscsi version will introduce async reconnects and zero events
are returned while libiscsi is waiting for a reconnect retry.

Signed-off-by: Peter Lieven <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>


  Commit: a6f2cb037a82fb8679e70e175cfbc879dd829e06
      
https://github.com/qemu/qemu/commit/a6f2cb037a82fb8679e70e175cfbc879dd829e06
  Author: Peter Maydell <address@hidden>
  Date:   2015-04-09 (Thu, 09 Apr 2015)

  Changed paths:
    M async.c
    M block/iscsi.c
    M block/qcow2.c
    M block/qcow2.h
    M hw/block/dataplane/virtio-blk.c
    M hw/block/virtio-blk.c
    M include/hw/virtio/virtio-blk.h
    A tests/qemu-iotests/130
    A tests/qemu-iotests/130.out
    M tests/qemu-iotests/group

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging

# gpg: Signature made Thu Apr  9 10:55:11 2015 BST using RSA key ID 81AB73C8
# gpg: Good signature from "Stefan Hajnoczi <address@hidden>"
# gpg:                 aka "Stefan Hajnoczi <address@hidden>"

* remotes/stefanha/tags/block-pull-request:
  block/iscsi: handle zero events from iscsi_which_events
  aio: strengthen memory barriers for bottom half scheduling
  virtio-blk: correctly dirty guest memory
  qcow2: Fix header update with overridden backing file

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/cf811fff2ae2...a6f2cb037a82