Re: x-blockdev-reopen & block-dirty-bitmaps

2020-02-14 Thread John Snow
On 2/14/20 3:19 PM, Kevin Wolf wrote: > Am 14.02.2020 um 19:54 hat John Snow geschrieben: >> Hi, what work remains to make this a stable interface, is it known? >> >> We're having a problem with bitmaps where in some cases libvirt wants to >> commit an image back down to a base image but -- for

Re: x-blockdev-reopen & block-dirty-bitmaps

2020-02-14 Thread Kevin Wolf
Am 14.02.2020 um 19:54 hat John Snow geschrieben: > Hi, what work remains to make this a stable interface, is it known? > > We're having a problem with bitmaps where in some cases libvirt wants to > commit an image back down to a base image but -- for various reasons -- > the bitmap was left enabl

[PATCH 6/7] commit: Expose on-error option in QMP

2020-02-14 Thread Kevin Wolf
Now that the error handling in the common block job is fixed, we can expose the on-error option in QMP instead of hard-coding it as 'report' in qmp_block_commit(). This fulfills the promise that the old comment in that function made, even if a bit later than expected: "This will be part of the QMP

[PATCH 4/7] commit: Inline commit_populate()

2020-02-14 Thread Kevin Wolf
commit_populate() is a very short function and only called in a single place. Its return value doesn't tell us whether an error happened while reading or writing, which would be necessary for sending the right data in the BLOCK_JOB_ERROR QMP event. Signed-off-by: Kevin Wolf --- block/commit.c |

[PATCH 2/7] commit: Remove unused bytes_written

2020-02-14 Thread Kevin Wolf
The bytes_written variable is only ever written to, it serves no purpose. This has actually been the case since the commit job was first introduced in commit 747ff602636. Signed-off-by: Kevin Wolf --- block/commit.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/block/commit.c b/block/comm

[PATCH 5/7] commit: Fix is_read for block_job_error_action()

2020-02-14 Thread Kevin Wolf
block_job_error_action() needs to know if reading from the top node or writing to the base node failed so that it can set the right 'operation' in the BLOCK_JOB_ERROR QMP event. Signed-off-by: Kevin Wolf --- block/commit.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a

[PATCH 7/7] iotests: Test error handling policies with block-commit

2020-02-14 Thread Kevin Wolf
This tests both read failure (from the top node) and write failure (to the base node) for on-error=report/stop/ignore. As block-commit actually starts two different types of block jobs (mirror.c for committing the active later, commit.c for intermediate layers), all tests are run for both cases.

[PATCH 3/7] commit: Fix argument order for block_job_error_action()

2020-02-14 Thread Kevin Wolf
The block_job_error_action() error call in the commit job gives the on_err and is_read arguments in the wrong order. Fix this. (Of course, hard-coded is_read = false is wrong, too, but that's a separate problem for a separate patch.) Signed-off-by: Kevin Wolf --- block/commit.c | 2 +- 1 file c

[PATCH 0/7] commit: Expose on-error option in QMP

2020-02-14 Thread Kevin Wolf
All other block jobs already provide a QMP option to control the error handling policy. It's time to add it to commit, too. Peter, I guess libvirt wants to expose this? Nir, as you would probably assume, this is motivated by the recent finding that VDSM has to preallocate the theoretical maximum

[PATCH 1/7] qapi: Document meaning of 'ignore' BlockdevOnError for jobs

2020-02-14 Thread Kevin Wolf
It is not obvious what 'ignore' actually means for block jobs: It could be continuing the job and returning success in the end despite the error (no block job does this). It could also mean continuing and returning failure in the end (this is what stream does). And it can mean retrying the failed r

x-blockdev-reopen & block-dirty-bitmaps

2020-02-14 Thread John Snow
Hi, what work remains to make this a stable interface, is it known? We're having a problem with bitmaps where in some cases libvirt wants to commit an image back down to a base image but -- for various reasons -- the bitmap was left enabled in the backing image, so it would accrue new writes durin

[PATCH 4/5] aio-posix: make AioHandler deletion O(1)

2020-02-14 Thread Stefan Hajnoczi
It is not necessary to scan all AioHandlers for deletion. Keep a list of deleted handlers instead of scanning the full list of all handlers. The AioHandler->deleted field can be dropped. Let's check if the handler has been inserted into the deleted list instead. Add a new QLIST_IS_INSERTED() AP

[PATCH 5/5] aio-posix: make AioHandler dispatch O(1) with epoll

2020-02-14 Thread Stefan Hajnoczi
File descriptor monitoring is O(1) with epoll(7), but aio_dispatch_handlers() still scans all AioHandlers instead of dispatching just those that are ready. This makes aio_poll() O(n) with respect to the total number of registered handlers. Add a local ready_list to aio_poll() so that each nested

[PATCH 2/5] aio-posix: don't pass ns timeout to epoll_wait()

2020-02-14 Thread Stefan Hajnoczi
Don't pass the nanosecond timeout into epoll_wait(), which expects milliseconds. The epoll_wait() timeout value does not matter if qemu_poll_ns() determined that the poll fd is ready, but passing a value in the wrong units is still ugly. Pass a 0 timeout to epoll_wait() instead. Signed-off-by: S

[PATCH 3/5] qemu/queue.h: add QLIST_SAFE_REMOVE()

2020-02-14 Thread Stefan Hajnoczi
QLIST_REMOVE() assumes the element is in a list. It also leaves the element's linked list pointers dangling. Introduce a safe version of QLIST_REMOVE() and convert open-coded instances of this pattern. Signed-off-by: Stefan Hajnoczi --- block.c | 5 + chardev/spice.c |

[PATCH 1/5] aio-posix: fix use after leaving scope in aio_poll()

2020-02-14 Thread Stefan Hajnoczi
epoll_handler is a stack variable and must not be accessed after it goes out of scope: if (aio_epoll_check_poll(ctx, pollfds, npfd, timeout)) { AioHandler epoll_handler; ... add_pollfd(&epoll_handler); ret = aio_epoll(ctx, pollfds, npfd, timeout);

[PATCH 0/5] aio-posix: towards an O(1) event loop

2020-02-14 Thread Stefan Hajnoczi
This patch series makes AioHandler deletion and dispatch O(1) with respect to the total number of registered handlers. The event loop has scalability problems when many AioHandlers are registered because it is O(n). Linux epoll(7) is used to avoid scanning over all pollfds but parts of the code s

Re: [PATCH] Report stringified errno in VFIO related errors

2020-02-14 Thread Michal Privoznik
On 2/14/20 4:49 PM, Alex Williamson wrote: On Fri, 14 Feb 2020 10:19:50 +0100 Michal Privoznik wrote: Do you guys want me to file a bug? Probably a good idea. Thanks, Since I'm reproducing this against upstream, I've reported it here: https://bugs.launchpad.net/qemu/+bug/186 Michal

Re: [PATCH] Report stringified errno in VFIO related errors

2020-02-14 Thread Alex Williamson
On Fri, 14 Feb 2020 10:19:50 +0100 Michal Privoznik wrote: > On 2/14/20 9:47 AM, Michal Privoznik wrote: > > In a few places we report errno formatted as a negative integer. > > This is not as user friendly as it can be. Use strerror() and/or > > error_setg_errno() instead. > > > > Signed-off-by

Re: [PATCH 0/3] qcow2: Fix write/copy error path with data file

2020-02-14 Thread Kevin Wolf
Am 11.02.2020 um 10:48 hat Kevin Wolf geschrieben: > Kevin Wolf (3): > qcow2: update_refcount(): Reset old_table_index after > qcow2_cache_put() > qcow2: Fix qcow2_alloc_cluster_abort() for external data file > iotests: Test copy offloading with external data file Applied to the block br

Re: [PATCH] block/vvfat: Do not unref qcow on closing backing bdrv

2020-02-14 Thread Kevin Wolf
Am 09.02.2020 um 18:51 hat Hikaru Nishida geschrieben: > Before this commit, BDRVVVFATState.qcow is unrefed in write_target_close > on closing backing bdrv of vvfat. However, qcow bdrv is opend as a child > of vvfat in enable_write_target() so it will be also unrefed on closing > vvfat itself. This

Re: [PATCH] qcow2: Fix alignment checks in encrypted images

2020-02-14 Thread Kevin Wolf
Am 13.02.2020 um 18:16 hat Alberto Garcia geschrieben: > I/O requests to encrypted media should be aligned to the sector size > used by the underlying encryption method, not to BDRV_SECTOR_SIZE. > Fortunately this doesn't break anything at the moment because > both existing QCRYPTO_BLOCK_*_SECTOR_S

Re: [PATCH] Report stringified errno in VFIO related errors

2020-02-14 Thread Philippe Mathieu-Daudé
On Fri, Feb 14, 2020 at 10:20 AM Michal Privoznik wrote: > On 2/14/20 9:47 AM, Michal Privoznik wrote: > > In a few places we report errno formatted as a negative integer. > > This is not as user friendly as it can be. Use strerror() and/or > > error_setg_errno() instead. > > > > Signed-off-by: Mi

Re: [PATCH] Report stringified errno in VFIO related errors

2020-02-14 Thread Michal Privoznik
On 2/14/20 9:47 AM, Michal Privoznik wrote: In a few places we report errno formatted as a negative integer. This is not as user friendly as it can be. Use strerror() and/or error_setg_errno() instead. Signed-off-by: Michal Privoznik --- hw/vfio/common.c| 2 +- util/vfio-helpers.c | 6 ++