qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 8e28b6: qemu-img: properly list formats which


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] 8e28b6: qemu-img: properly list formats which have consist...
Date: Thu, 05 May 2022 06:09:21 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 8e28b65f52637917d3d02ade4e0ae85442de9f86
      
https://github.com/qemu/qemu/commit/8e28b65f52637917d3d02ade4e0ae85442de9f86
  Author: Denis V. Lunev <den@openvz.org>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M docs/tools/qemu-img.rst

  Log Message:
  -----------
  qemu-img: properly list formats which have consistency check implemented

Simple grep for the .bdrv_co_check callback presence gives the following
list of block drivers
* QED
* VDI
* VHDX
* VMDK
* Parallels
which have this callback. The presense of the callback means that
consistency check is supported.

The patch updates documentation accordingly.

Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220407083932.531965-1-den@openvz.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 31009d13cc505b9569971fbbe50266c1727ba5db
      
https://github.com/qemu/qemu/commit/31009d13cc505b9569971fbbe50266c1727ba5db
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M docs/interop/vhost-user.rst

  Log Message:
  -----------
  docs/vhost-user: Clarifications for VHOST_USER_ADD/REM_MEM_REG

The specification for VHOST_USER_ADD/REM_MEM_REG messages is unclear
in several points, which has led to clients having incompatible
implementations. This changes the specification to be more explicit
about them:

* VHOST_USER_ADD_MEM_REG is not specified as receiving a file
  descriptor, though it obviously does need to do so. All
  implementations agree on this one, fix the specification.

* VHOST_USER_REM_MEM_REG is not specified as receiving a file
  descriptor either, and it also has no reason to do so. rust-vmm does
  not send file descriptors for removing a memory region (in agreement
  with the specification), libvhost-user and QEMU do (which is a bug),
  though libvhost-user doesn't actually make any use of it.

  Change the specification so that for compatibility QEMU's behaviour
  becomes legal, even if discouraged, but rust-vmm's behaviour becomes
  the explicitly recommended mode of operation.

* VHOST_USER_ADD_MEM_REG doesn't have a documented return value, which
  is the desired behaviour in the non-postcopy case. It also implemented
  like this in QEMU and rust-vmm, though libvhost-user is buggy and
  sometimes sends an unexpected reply. This will be fixed in a separate
  patch.

  However, in postcopy mode it does reply like VHOST_USER_SET_MEM_TABLE.
  This behaviour is shared between libvhost-user and QEMU; rust-vmm
  doesn't implement postcopy mode yet. Mention it explicitly in the
  spec.

* The specification doesn't mention how VHOST_USER_REM_MEM_REG
  identifies the memory region to be removed. Change it to describe the
  existing behaviour of libvhost-user (guest address, user address and
  size must match).

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20220407133657.155281-2-kwolf@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 5ebfdeb21223e0406a711decbb2baceb5ec8c416
      
https://github.com/qemu/qemu/commit/5ebfdeb21223e0406a711decbb2baceb5ec8c416
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M subprojects/libvhost-user/libvhost-user.c

  Log Message:
  -----------
  libvhost-user: Fix extra vu_add/rem_mem_reg reply

Outside of postcopy mode, neither VHOST_USER_ADD_MEM_REG nor
VHOST_USER_REM_MEM_REG are supposed to send a reply unless explicitly
requested with the need_reply flag. Their current implementation always
sends a reply, even if it isn't requested. This confuses the master
because it will interpret the reply as a reply for the next message for
which it actually expects a reply.

need_reply is already handled correctly by vu_dispatch(), so just don't
send a reply in the non-postcopy part of the message handler for these
two commands.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20220407133657.155281-3-kwolf@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: a81d8d4a7203e4be392f9ad37af104759b7cbda5
      
https://github.com/qemu/qemu/commit/a81d8d4a7203e4be392f9ad37af104759b7cbda5
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M hw/virtio/vhost-user.c
    M subprojects/libvhost-user/libvhost-user.c

  Log Message:
  -----------
  vhost-user: Don't pass file descriptor for VHOST_USER_REM_MEM_REG

The spec clarifies now that QEMU should not send a file descriptor in a
request to remove a memory region. Change it accordingly.

For libvhost-user, this is a bug fix that makes it compatible with
rust-vmm's implementation that doesn't send a file descriptor. Keep
accepting, but ignoring a file descriptor for compatibility with older
QEMU versions.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20220407133657.155281-4-kwolf@redhat.com>
Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 15aee7ac9587562b1d021959dedc2bbb7e9a9fb3
      
https://github.com/qemu/qemu/commit/15aee7ac9587562b1d021959dedc2bbb7e9a9fb3
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M block.c
    M include/block/block-global-state.h
    M include/block/block-io.h

  Log Message:
  -----------
  block: Classify bdrv_get_flags() as I/O function

This function is safe to call in an I/O context, and qcow2_do_open()
does so (invoked in an I/O context by qcow2_co_invalidate_cache()).

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220427114057.36651-2-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 06e9cd19a4e9acf8d24327361a999943d846f607
      
https://github.com/qemu/qemu/commit/06e9cd19a4e9acf8d24327361a999943d846f607
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M block/qcow2.c

  Log Message:
  -----------
  qcow2: Do not reopen data_file in invalidate_cache

qcow2_co_invalidate_cache() closes and opens the qcow2 file, by calling
qcow2_close() and qcow2_do_open().  These two functions must thus be
usable from both a global-state and an I/O context.

As they are, they are not safe to call in an I/O context, because they
use bdrv_unref_child() and bdrv_open_child() to close/open the data_file
child, respectively, both of which are global-state functions.  When
used from qcow2_co_invalidate_cache(), we do not need to close/open the
data_file child, though (we do not do this for bs->file or bs->backing
either), and so we should skip it in the qcow2_co_invalidate_cache()
path.

To do so, add a parameter to qcow2_do_open() and qcow2_close() to make
them skip handling s->data_file, and have qcow2_co_invalidate_cache()
exempt it from the memset() on the BDRVQcow2State.

(Note that the QED driver similarly closes/opens the QED image by
invoking bdrv_qed_close()+bdrv_qed_do_open(), but both functions seem
safe to use in an I/O context.)

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/945
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220427114057.36651-3-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: ccfaf783c8eecae99b671e4e892954c9226ef5dc
      
https://github.com/qemu/qemu/commit/ccfaf783c8eecae99b671e4e892954c9226ef5dc
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M include/qemu/main-loop.h

  Log Message:
  -----------
  Revert "main-loop: Disable GLOBAL_STATE_CODE() assertions"

This reverts commit b1c073490553f80594b903ceedfc7c1aef6b1b19.  (We
wanted to do so once the 7.1 tree opens, which has happened.  The issue
reported in https://gitlab.com/qemu-project/qemu/-/issues/945 should be
fixed by the preceding patches.)

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220427114057.36651-4-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 96edda8f142928c627f93b3ad74c64edf86cc22f
      
https://github.com/qemu/qemu/commit/96edda8f142928c627f93b3ad74c64edf86cc22f
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    A tests/qemu-iotests/tests/export-incoming-iothread
    A tests/qemu-iotests/tests/export-incoming-iothread.out

  Log Message:
  -----------
  iotests: Add regression test for issue 945

Create a VM with a BDS in an iothread, add -incoming defer to the
command line, and then export this BDS via NBD.  Doing so should not
fail an assertion.

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220427114057.36651-5-hreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 6d17e2879854d7d0e623c06a9286085e97bf3545
      
https://github.com/qemu/qemu/commit/6d17e2879854d7d0e623c06a9286085e97bf3545
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M block/vmdk.c

  Log Message:
  -----------
  block/vmdk: Fix reopening bs->file

VMDK disk data is stored in extents, which may or may not be separate
from bs->file.  VmdkExtent.file points to where they are stored.  Each
that is stored in bs->file will simply reuse the exact pointer value of
bs->file.

(That is why vmdk_free_extents() will unref VmdkExtent.file (e->file)
only if e->file != bs->file.)

Reopen operations can change bs->file (they will replace the whole
BdrvChild object, not just the BDS stored in that BdrvChild), and then
we will need to change all .file pointers of all such VmdkExtents to
point to the new BdrvChild.

In vmdk_reopen_prepare(), we have to check which VmdkExtents are
affected, and in vmdk_reopen_commit(), we can modify them.  We have to
split this because:
- The new BdrvChild is created only after prepare, so we can change
  VmdkExtent.file only in commit
- In commit, there no longer is any (valid) reference to the old
  BdrvChild object, so there would be nothing to compare VmdkExtent.file
  against to see whether it was equal to bs->file before reopening
  (There is BDRVReopenState.old_file_bs, but the old bs->file
  BdrvChild's .bs pointer will be NULL-ed when the new BdrvChild is
  created, and so we cannot compare VmdkExtent.file->bs against
  BDRVReopenState.old_file_bs)

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220314162719.65384-2-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: ecf3200703df77f9f5ac95e3cc8e1379e40cb36a
      
https://github.com/qemu/qemu/commit/ecf3200703df77f9f5ac95e3cc8e1379e40cb36a
  Author: Hanna Reitz <hreitz@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    A tests/qemu-iotests/tests/reopen-file
    A tests/qemu-iotests/tests/reopen-file.out

  Log Message:
  -----------
  iotests/reopen-file: Test reopening file child

This should work for all format drivers that support reopening, so test
it.

(This serves as a regression test for HEAD^: This test used to fail for
VMDK before HEAD^.)

Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220314162719.65384-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 34145a307d849d0b6734d0222a7aa0bb9eef7407
      
https://github.com/qemu/qemu/commit/34145a307d849d0b6734d0222a7aa0bb9eef7407
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M util/coroutine-ucontext.c

  Log Message:
  -----------
  coroutine-ucontext: use QEMU_DEFINE_STATIC_CO_TLS()

Thread-Local Storage variables cannot be used directly from coroutine
code because the compiler may optimize TLS variable accesses across
qemu_coroutine_yield() calls. When the coroutine is re-entered from
another thread the TLS variables from the old thread must no longer be
used.

Use QEMU_DEFINE_STATIC_CO_TLS() for the current and leader variables.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220307153853.602859-2-stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: ac387a08a9c9f6b36757da912f0339c25f421f90
      
https://github.com/qemu/qemu/commit/ac387a08a9c9f6b36757da912f0339c25f421f90
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M util/qemu-coroutine.c

  Log Message:
  -----------
  coroutine: use QEMU_DEFINE_STATIC_CO_TLS()

Thread-Local Storage variables cannot be used directly from coroutine
code because the compiler may optimize TLS variable accesses across
qemu_coroutine_yield() calls. When the coroutine is re-entered from
another thread the TLS variables from the old thread must no longer be
used.

Use QEMU_DEFINE_STATIC_CO_TLS() for the current and leader variables.
The alloc_pool QSLIST needs a typedef so the return value of
get_ptr_alloc_pool() can be stored in a local variable.

One example of why this code is necessary: a coroutine that yields
before calling qemu_coroutine_create() to create another coroutine is
affected by the TLS issue.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220307153853.602859-3-stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: c1fe694357a328c807ae3cc6961c19e923448fcc
      
https://github.com/qemu/qemu/commit/c1fe694357a328c807ae3cc6961c19e923448fcc
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M util/coroutine-win32.c

  Log Message:
  -----------
  coroutine-win32: use QEMU_DEFINE_STATIC_CO_TLS()

Thread-Local Storage variables cannot be used directly from coroutine
code because the compiler may optimize TLS variable accesses across
qemu_coroutine_yield() calls. When the coroutine is re-entered from
another thread the TLS variables from the old thread must no longer be
used.

Use QEMU_DEFINE_STATIC_CO_TLS() for the current and leader variables.

I think coroutine-win32.c could get away with __thread because the
variables are only used in situations where either the stale value is
correct (current) or outside coroutine context (loading leader when
current is NULL). Due to the difficulty of being sure that this is
really safe in all scenarios it seems worth converting it anyway.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20220307153853.602859-4-stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>


  Commit: 5d5104260222cd7ffaaeb555727808f479e7103b
      
https://github.com/qemu/qemu/commit/5d5104260222cd7ffaaeb555727808f479e7103b
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2022-05-04 (Wed, 04 May 2022)

  Changed paths:
    M block.c
    M block/qcow2.c
    M block/vmdk.c
    M docs/interop/vhost-user.rst
    M docs/tools/qemu-img.rst
    M hw/virtio/vhost-user.c
    M include/block/block-global-state.h
    M include/block/block-io.h
    M include/qemu/main-loop.h
    M subprojects/libvhost-user/libvhost-user.c
    A tests/qemu-iotests/tests/export-incoming-iothread
    A tests/qemu-iotests/tests/export-incoming-iothread.out
    A tests/qemu-iotests/tests/reopen-file
    A tests/qemu-iotests/tests/reopen-file.out
    M util/coroutine-ucontext.c
    M util/coroutine-win32.c
    M util/qemu-coroutine.c

  Log Message:
  -----------
  Merge tag 'for-upstream' of git://repo.or.cz/qemu/kevin into staging

Block layer patches

- Fix and re-enable GLOBAL_STATE_CODE assertions
- vhost-user: Fixes for VHOST_USER_ADD/REM_MEM_REG
- vmdk: Fix reopening bs->file
- coroutine: use QEMU_DEFINE_STATIC_CO_TLS()
- docs/qemu-img: Fix list of formats which implement check

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmJyi+YRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9aphxAAt0sXEOWlcIeU87NOk+V30rRiBup0K/HZ
# wqsE6e0EMbygmC2aS/xqNu3naQ/TMY6UaoVBWSpf0D3sK2GnWEJW8bjV05ObZBwp
# 6QUgqljk1QAAVv0o2/nViAcV8mEW+OzZLveP+qxFRNlNGoJDsbGzWj939SHM13eu
# ZD+/GGs/qXL3Gxp6adhOBjxbXYjvxm13F3pVjoyAugjMSqoSuCI0eXu1xkwXNHSP
# /wqObH3dQSzIvEXfE/1BOp3ofZwvg+XzeZ6MM4I/lvHDZWuQBfCQcBYKL9mMNWGc
# ijFEeolWt7hER50ik4XPvBmbj0jU2nPXQwo1XcFeWX3MSoNsha2jCZsz4LqzadIN
# YijGQHmkfDRmG2LSoIGcgM7chdwj88K8pfMnrrTsVEB6Dl4QrK6FjXviL5mG+rcX
# 5FbKpgRwm3fmtug7Ttpgm1LJQmwK5A3YPenPH+CC2FoK3Rje46ZoMwQR5PBuHvM1
# rg9RB01eGJQGrw5Rt3VFk7304O/yT2J5m96x6CMejx4CuGK78VpkBC54HixTTh0R
# nXxLLZdqawVqwrPP6sE02FEajM931///nhU6fuN/832m3bYUsfM8SZNVqJh5xoex
# SK8x/a5HnTIkp7kys3f4juc+jzb4Yvka8IBIZi/gqzoqf8POGKLBCTpEXa3lBWIT
# gnCCnWWEdgY=
# =ETW/
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 04 May 2022 09:21:26 AM CDT
# gpg:                using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg:                issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]

* tag 'for-upstream' of git://repo.or.cz/qemu/kevin:
  coroutine-win32: use QEMU_DEFINE_STATIC_CO_TLS()
  coroutine: use QEMU_DEFINE_STATIC_CO_TLS()
  coroutine-ucontext: use QEMU_DEFINE_STATIC_CO_TLS()
  iotests/reopen-file: Test reopening file child
  block/vmdk: Fix reopening bs->file
  iotests: Add regression test for issue 945
  Revert "main-loop: Disable GLOBAL_STATE_CODE() assertions"
  qcow2: Do not reopen data_file in invalidate_cache
  block: Classify bdrv_get_flags() as I/O function
  vhost-user: Don't pass file descriptor for VHOST_USER_REM_MEM_REG
  libvhost-user: Fix extra vu_add/rem_mem_reg reply
  docs/vhost-user: Clarifications for VHOST_USER_ADD/REM_MEM_REG
  qemu-img: properly list formats which have consistency check implemented

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>


Compare: https://github.com/qemu/qemu/compare/1fba9dc71a17...5d5104260222



reply via email to

[Prev in Thread] Current Thread [Next in Thread]