Re: [Qemu-block] [Qemu-devel] [PATCH v2] blockdev: Print a warning for legacy drive options that belong to -device

2017-05-29 Thread Markus Armbruster
Thomas Huth writes: > We likely do not want to carry these legacy -drive options along forever. > Let's emit a deprecation warning for the -drive options that have a > replacement with the -device option, so that the (hopefully few) remaining > users are aware of this and can

[Qemu-block] [RFC] Making 'block-stream', and 'block-commit' accept node-name

2017-05-29 Thread Kashyap Chamarthy
Observe the following ('qmp-shell', for brevity) invocation of the four major types (stream, commit, mirror, backup) of live block operations: (QEMU) block-stream device=node-D base=a.qcow2 job-id=job-block-stream (QEMU) block-commit device=node-D base=a.qcow2 top=b.qcow2

Re: [Qemu-block] [PATCH 09/25] block/dirty-bitmap: add readonly field to BdrvDirtyBitmap

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > It will be needed in following commits for persistent bitmaps. > If bitmap is loaded from read-only storage (and we can't mark it > "in use" in this storage) corresponding BdrvDirtyBitmap should be > read-only. > > Signed-off-by: Vladimir

Re: [Qemu-block] [PATCH 25/25] block: release persistent bitmaps on inactivate

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > We should release them here to reload on invalidate cache. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block.c | 4 > block/dirty-bitmap.c | 29

Re: [Qemu-block] [PATCH 24/25] qmp: block-dirty-bitmap-remove: remove persistent

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Remove persistent bitmap from the storage on block-dirty-bitmap-remove. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Max Reitz > Reviewed-by: John Snow >

Re: [Qemu-block] [PATCH 21/25] iotests: test qcow2 persistent dirty bitmap

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > tests/qemu-iotests/165 | 105 > + > tests/qemu-iotests/165.out | 5 +++ > tests/qemu-iotests/group | 1 +

Re: [Qemu-block] [PATCH 15/25] qcow2: add persistent dirty bitmaps support

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Store persistent dirty bitmaps in qcow2 image. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-bitmap.c | 475 > +++ > block/qcow2.c|

Re: [Qemu-block] [PATCH 13/25] block: introduce persistent dirty bitmaps

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > New field BdrvDirtyBitmap.persistent means, that bitmap should be saved > by format driver in .bdrv_close and .bdrv_inactivate. No format driver > supports it for now. > > Signed-off-by: Vladimir Sementsov-Ogievskiy

Re: [Qemu-block] [PATCH 12/25] block: bdrv_close: release bitmaps after drv->bdrv_close

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Release bitmaps after 'if (bs->drv) { ... }' block. This will allow > format driver to save persistent bitmaps, which will appear in following > commits. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- >

Re: [Qemu-block] [PATCH 10/25] qcow2: autoloading dirty bitmaps

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Auto loading bitmaps are bitmaps in Qcow2, with the AUTO flag set. They > are loaded when the image is opened and become BdrvDirtyBitmaps for the > corresponding drive. > > Extra data in bitmaps is not supported for now. > >

Re: [Qemu-block] [Qemu-devel] [PATCH v2] blockdev: Print a warning for legacy drive options that belong to -device

2017-05-29 Thread Thomas Huth
On 12.05.2017 12:33, Thomas Huth wrote: > We likely do not want to carry these legacy -drive options along forever. > Let's emit a deprecation warning for the -drive options that have a > replacement with the -device option, so that the (hopefully few) remaining > users are aware of this and can

Re: [Qemu-block] [PATCH v3 1/2] iotests: Use absolute paths for executables

2017-05-29 Thread Max Reitz
On 2017-05-29 17:55, Eric Blake wrote: > On 05/29/2017 10:46 AM, Max Reitz wrote: > >>> If you switch all of these to $(realpath -- "$(type -p "$QEMU_...")"), >>> you can add: >> >> I'd love to, but this is what type -p outputs for me: >> >> $ type -p qemu-img >> qemu-img is /usr/bin/qemu-img >

Re: [Qemu-block] [PATCH v3 1/2] iotests: Use absolute paths for executables

2017-05-29 Thread Eric Blake
On 05/29/2017 10:46 AM, Max Reitz wrote: >> If you switch all of these to $(realpath -- "$(type -p "$QEMU_...")"), >> you can add: > > I'd love to, but this is what type -p outputs for me: > > $ type -p qemu-img > qemu-img is /usr/bin/qemu-img Huh? That's plain 'type' output. Are you sure

Re: [Qemu-block] [PATCH 09/25] block/dirty-bitmap: add readonly field to BdrvDirtyBitmap

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > It will be needed in following commits for persistent bitmaps. > If bitmap is loaded from read-only storage (and we can't mark it > "in use" in this storage) corresponding BdrvDirtyBitmap should be > read-only. > > Signed-off-by: Vladimir

Re: [Qemu-block] [PATCH v3 1/2] iotests: Use absolute paths for executables

2017-05-29 Thread Max Reitz
On 2017-05-29 17:42, Eric Blake wrote: > On 05/29/2017 10:23 AM, Max Reitz wrote: >> A user may specify a relative path for accessing qemu, qemu-img, etc. >> through environment variables ($QEMU_PROG and friends) or a symlink. >> >> If a test decides to change its working directory, relative paths

Re: [Qemu-block] [PATCH v3 1/2] iotests: Use absolute paths for executables

2017-05-29 Thread Eric Blake
On 05/29/2017 10:23 AM, Max Reitz wrote: > A user may specify a relative path for accessing qemu, qemu-img, etc. > through environment variables ($QEMU_PROG and friends) or a symlink. > > If a test decides to change its working directory, relative paths will > cease to work, however. Work around

Re: [Qemu-block] [PATCH 08/25] qcow2: add bitmaps extension

2017-05-29 Thread Max Reitz
On 2017-05-03 14:25, Vladimir Sementsov-Ogievskiy wrote: > Add bitmap extension as specified in docs/specs/qcow2.txt. > For now, just mirror extension header into Qcow2 state and check > constraints. Also, calculate refcounts for qcow2 bitmaps, to not break > qemu-img check. > > For now, disable

[Qemu-block] [PATCH v3 2/2] iotests: Add test for colon handling

2017-05-29 Thread Max Reitz
Reviewed-by: Eric Blake Signed-off-by: Max Reitz --- tests/qemu-iotests/126 | 105 + tests/qemu-iotests/126.out | 23 ++ tests/qemu-iotests/group | 1 + 3 files changed, 129 insertions(+) create

[Qemu-block] [PATCH v3 1/2] iotests: Use absolute paths for executables

2017-05-29 Thread Max Reitz
A user may specify a relative path for accessing qemu, qemu-img, etc. through environment variables ($QEMU_PROG and friends) or a symlink. If a test decides to change its working directory, relative paths will cease to work, however. Work around this by making all of the paths to programs that

[Qemu-block] [PATCH v3 0/2] iotests: Add test for colon handling

2017-05-29 Thread Max Reitz
This is a v3 for "block: Fix backing paths for filenames with colons". Kevin reported that the test added there does not work if the test programs are specified with relative paths (because the new test changes its working directory), so we/I dropped the test from the queue and here it is again.

[Qemu-block] [PULL 14/15] block: Fix backing paths for filenames with colons

2017-05-29 Thread Kevin Wolf
From: Max Reitz path_combine() naturally tries to preserve a protocol prefix. However, it recognizes such a prefix by scanning for the first colon; which is different from what path_has_protocol() does: There only is a protocol prefix if there is a colon before the first

[Qemu-block] [PULL 15/15] block/file-*: *_parse_filename() and colons

2017-05-29 Thread Kevin Wolf
From: Max Reitz The file drivers' *_parse_filename() implementations just strip the optional protocol prefix off the filename. However, for e.g. "file:foo:bar", this would lead to "foo:bar" being stored as the BDS's filename which looks like it should be managed using the

[Qemu-block] [PULL 10/15] qemu-img: introduce --target-image-opts for 'convert' command

2017-05-29 Thread Kevin Wolf
From: "Daniel P. Berrange" The '--image-opts' flag indicates whether the source filename includes options. The target filename has to remain in the plain filename format though, since it needs to be passed to bdrv_create(). When using --skip-create though, it would be

[Qemu-block] [PULL 12/15] qemu-img: Fix leakage of options on error

2017-05-29 Thread Kevin Wolf
From: Fam Zheng Reported by Coverity. Signed-off-by: Fam Zheng Message-id: 20170515141014.25793-1-f...@redhat.com Reviewed-by: Eric Blake Signed-off-by: Max Reitz --- qemu-img.c | 1 + 1 file changed, 1 insertion(+)

[Qemu-block] [PULL 13/15] block: Tweak error message related to qemu-img amend

2017-05-29 Thread Kevin Wolf
From: Eric Blake When converting a 1.1 image down to 0.10, qemu-iotests 060 forces a contrived failure where allocating a cluster used to replace a zero cluster reads unaligned data. Since it is a zero cluster rather than a data cluster being converted, changing the error

[Qemu-block] [PULL 09/15] qemu-img: fix --image-opts usage with dd command

2017-05-29 Thread Kevin Wolf
From: "Daniel P. Berrange" The --image-opts flag can only be used to affect the parsing of the source image. The target image has to be specified in the traditional style regardless, since it needs to be passed to the bdrv_create() API which does not support the new style

[Qemu-block] [PULL 08/15] qemu-img: add support for --object with 'dd' command

2017-05-29 Thread Kevin Wolf
From: "Daniel P. Berrange" The qemu-img dd command added --image-opts support, but missed the corresponding --object support. This prevented passing secrets (eg auth passwords) needed by certain disk images. Reviewed-by: Fam Zheng Reviewed-by: Max Reitz

[Qemu-block] [PULL 07/15] qemu-img: Fix documentation of convert

2017-05-29 Thread Kevin Wolf
From: Fam Zheng It got lost in commit a8d16f9ca "qemu-img: Update documentation for -U". Reported-by: Max Reitz Signed-off-by: Fam Zheng Message-id: 20170515103551.31313-1-f...@redhat.com Reviewed-by: Eric Blake

[Qemu-block] [PULL 06/15] qcow2: remove extra local_error variable

2017-05-29 Thread Kevin Wolf
From: Alberto Garcia Commit d7086422b1c1e75e320519cfe26176db6ec97a37 added a local_err variable global to the qcow2_amend_options() function, so there's no need to have this other one. Signed-off-by: Alberto Garcia Message-id:

[Qemu-block] [PULL 03/15] iotests: 147: Don't test inet6 if not available

2017-05-29 Thread Kevin Wolf
From: Fam Zheng This is the case in our docker tests, as we use --net=none there. Skip this method. Signed-off-by: Fam Zheng Signed-off-by: Kevin Wolf --- tests/qemu-iotests/147 | 7 +++ 1 file changed, 7 insertions(+) diff --git

[Qemu-block] [PULL 05/15] mirror: Drop permissions on s->target on completion

2017-05-29 Thread Kevin Wolf
This fixes an assertion failure that was triggered by qemu-iotests 129 on some CI host, while the same test case didn't seem to fail on other hosts. Essentially the problem is that the blk_unref(s->target) in mirror_exit() doesn't necessarily mean that the BlockBackend goes away immediately. It

[Qemu-block] [PULL 04/15] nvme: Add support for Controller Memory Buffers

2017-05-29 Thread Kevin Wolf
From: Stephen Bates Implement NVMe Controller Memory Buffers (CMBs) which were added in version 1.2 of the NVMe Specification. This patch adds an optional argument (cmb_size_mb) which indicates the size of the CMB (in MB). Currently only the Submission Queue Support (SQS) is

[Qemu-block] [PULL 01/15] stream: fix crash in stream_start() when block_job_create() fails

2017-05-29 Thread Kevin Wolf
From: Alberto Garcia The code that tries to reopen a BlockDriverState in stream_start() when the creation of a new block job fails crashes because it attempts to dereference a pointer that is known to be NULL. This is a regression introduced in

[Qemu-block] [PULL 00/15] Block layer patches

2017-05-29 Thread Kevin Wolf
The following changes since commit 9964e96dccf7f7c936ee854a795415d19b60: Merge remote-tracking branch 'jasowang/tags/net-pull-request' into staging (2017-05-23 15:01:31 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git tags/for-upstream for you to fetch

[Qemu-block] [PULL 02/15] qemu-iotests: Test streaming with missing job ID

2017-05-29 Thread Kevin Wolf
This adds a small test for the image streaming error path for failing block_job_create(), which would have found the null pointer dereference in commit a170a91f. Signed-off-by: Kevin Wolf Reviewed-by: Alberto Garcia Reviewed-by: Kashyap Chamarthy

Re: [Qemu-block] [PATCH 09/18] throttle-groups: protect throttled requests with a CoMutex

2017-05-29 Thread Alberto Garcia
On Thu 25 May 2017 06:32:16 PM CEST, Paolo Bonzini wrote: > Another possibility is to use tg->lock, which we're holding anyway in > both schedule_next_request and throttle_group_co_io_limits_intercept. > This would require open-coding the CoQueue however, so I've chosen this > alternative. > >

Re: [Qemu-block] [PATCH v7 20/20] docs: document encryption options for qcow, qcow2 and luks

2017-05-29 Thread Alberto Garcia
On Thu 25 May 2017 06:38:51 PM CEST, "Daniel P. Berrange" wrote: > Expand the image format docs to cover the new options for > the qcow, qcow2 and luks disk image formats > > Signed-off-by: Daniel P. Berrange Reviewed-by: Alberto Garcia

Re: [Qemu-block] [PATCH v7 17/20] block: remove all encryption handling APIs

2017-05-29 Thread Alberto Garcia
On Thu 25 May 2017 06:38:48 PM CEST, "Daniel P. Berrange" wrote: > Now that all encryption keys must be provided upfront via > the QCryptoSecret API and associated block driver properties > there is no need for any explicit encryption handling APIs > in the block layer.

Re: [Qemu-block] [PATCH] mirror: Drop permissions on s->target on completion

2017-05-29 Thread Max Reitz
On 2017-05-29 14:18, Kevin Wolf wrote: > This fixes an assertion failure that was triggered by qemu-iotests 129 > on some CI host, while the same test case didn't seem to fail on other > hosts. > > Essentially the problem is that the blk_unref(s->target) in > mirror_exit() doesn't necessarily

Re: [Qemu-block] [PATCH] mirror: Drop permissions on s->target on completion

2017-05-29 Thread Paolo Bonzini
On 29/05/2017 14:18, Kevin Wolf wrote: > This fixes an assertion failure that was triggered by qemu-iotests 129 > on some CI host, while the same test case didn't seem to fail on other > hosts. > > Essentially the problem is that the blk_unref(s->target) in > mirror_exit() doesn't necessarily

Re: [Qemu-block] [Qemu-devel] [PATCH] nbd: Fully initialize client in case of failed negotiation

2017-05-29 Thread Eric Blake
On 05/26/2017 10:04 PM, Eric Blake wrote: > If a non-NBD client connects to qemu-nbd, we would end up with > a SIGSEGV in nbd_cilent_put() because we were trying to > unregister the client's association to the export, even though > we skipped inserting the client into that list. Easy trigger > in

[Qemu-block] [PATCH] mirror: Drop permissions on s->target on completion

2017-05-29 Thread Kevin Wolf
This fixes an assertion failure that was triggered by qemu-iotests 129 on some CI host, while the same test case didn't seem to fail on other hosts. Essentially the problem is that the blk_unref(s->target) in mirror_exit() doesn't necessarily mean that the BlockBackend goes away immediately. It

Re: [Qemu-block] [PATCH 00/29] qed: Convert to coroutines

2017-05-29 Thread Paolo Bonzini
On 26/05/2017 22:21, Kevin Wolf wrote: > The qed block driver is one of the last remaining block drivers that use the > AIO callback style interfaces. This series converts it to the coroutine model > that other drivers are using and removes some AIO functions from the block > layer API afterwards.

Re: [Qemu-block] [Qemu-devel] [PATCH v7 19/20] qcow2: report encryption specific image information

2017-05-29 Thread Markus Armbruster
"Daniel P. Berrange" writes: > On Thu, May 25, 2017 at 02:52:30PM -0500, Eric Blake wrote: >> On 05/25/2017 11:38 AM, Daniel P. Berrange wrote: >> > Currently 'qemu-img info' reports a simple "encrypted: yes" >> > field. This is not very useful now that qcow2 can support >>