Re: [Qemu-block] [Qemu-devel] [PATCH v7 31/38] libqtest: Merge qtest_clock_*() with clock_*()

On 12.09.2017 15:35, Eric Blake wrote: > On 09/12/2017 05:45 AM, Thomas Huth wrote: >> On 11.09.2017 19:20, Eric Blake wrote: >>> Maintaining two layers of libqtest APIs, one that takes an explicit >>> QTestState object, and the other that uses the implicit global_qtest, >>> is annoying. In the

Re: [Qemu-block] [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them

On 09/13/2017 05:36 PM, Adam Wolfe Gordon via Qemu-devel wrote: > On Wed, Sep 13, 2017 at 2:53 PM, John Snow wrote: >> On 09/13/2017 12:44 PM, Adam Wolfe Gordon wrote: >>> Register a watcher with rbd so that we get notified when an image is >>> resized. Propagate resizes to

Re: [Qemu-block] [Qemu-devel] [PATCH v7 12/20] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

On 09/12/2017 04:31 PM, Eric Blake wrote: > Thanks to recent cleanups, all callers were scaling a return value > of sectors into bytes; do the scaling internally instead. > > Signed-off-by: Eric Blake > Reviewed-by: John Snow

Re: [Qemu-block] [Qemu-devel] [PATCH v7 11/20] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

On 09/12/2017 04:31 PM, Eric Blake wrote: > Thanks to recent cleanups, most callers were scaling a return value > of sectors into bytes (the exception, in qcow2-bitmap, will be > converted to byte-based iteration later). Update the interface to > do the scaling internally instead. > > In

Re: [Qemu-block] [Qemu-devel] [PATCH v7 07/20] dirty-bitmap: Track bitmap size by bytes

On 09/12/2017 04:31 PM, Eric Blake wrote: > We are still using an internal hbitmap that tracks a size in sectors, > with the granularity scaled down accordingly, because it lets us > use a shortcut for our iterators which are currently sector-based. > But there's no reason we can't track the

Re: [Qemu-block] [Qemu-devel] [PATCH v7 06/20] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

On 09/12/2017 04:31 PM, Eric Blake wrote: > We're already reporting bytes for bdrv_dirty_bitmap_granularity(); > mixing bytes and sectors in our return values is a recipe for > confusion. A later cleanup will convert dirty bitmap internals > to be entirely byte-based, but in the meantime, we

Re: [Qemu-block] [Qemu-devel] [PATCH v2 00/10] cleanup qemu-iotests

On 13/09/2017 09:59, Fam Zheng wrote: > On Wed, 09/13 08:47, Thomas Huth wrote: >> Meta comment: Could we maybe also rename "tests/qemu-iotests" to >> "tests/iotests" ? The "qemu" prefix sounds always very superfluous to me >> here... > > Sounds good, and saves typing for when this path is

Re: [Qemu-block] [PATCH] rbd: Detect rbd image resizes and propagate them

On Wed, Sep 13, 2017 at 3:21 PM, Jason Dillaman wrote: > On Wed, 2017-09-13 at 10:44 -0600, Adam Wolfe Gordon wrote: >> +parent = bs->inherits_from; >> +if (parent == NULL) { >> +error_report("bs %s does not have parent", >> bdrv_get_device_or_node_name(bs));

Re: [Qemu-block] [PATCH] rbd: Detect rbd image resizes and propagate them

On Wed, Sep 13, 2017 at 2:53 PM, John Snow wrote: > On 09/13/2017 12:44 PM, Adam Wolfe Gordon wrote: >> Register a watcher with rbd so that we get notified when an image is >> resized. Propagate resizes to parent block devices so that guest devices >> get resized without user

Re: [Qemu-block] [PATCH] osdep: Fix ROUND_UP(64-bit, 32-bit)

On 13/09/2017 23:03, Eric Blake wrote: > When using bit-wise operations that exploit the power-of-two > nature of the second argument of ROUND_UP(), we still need to > ensure that the mask is as wide as the first argument (done > by using addition of 0 to force proper arithmetic promotion). >

Re: [Qemu-block] [PATCH] rbd: Detect rbd image resizes and propagate them

On Wed, 2017-09-13 at 10:44 -0600, Adam Wolfe Gordon wrote: > Register a watcher with rbd so that we get notified when an image is > resized. Propagate resizes to parent block devices so that guest devices > get resized without user intervention. > > Signed-off-by: Adam Wolfe Gordon

Re: [Qemu-block] [Qemu-devel] [PATCH v4 00/23] make bdrv_get_block_status byte-based

On 09/13/2017 11:03 AM, Eric Blake wrote: > There are patches floating around to add NBD_CMD_BLOCK_STATUS, > but NBD wants to report status on byte granularity (even if the > reporting will probably be naturally aligned to sectors or even > much higher levels). I've therefore started the task of

[Qemu-block] [PATCH] osdep: Fix ROUND_UP(64-bit, 32-bit)

When using bit-wise operations that exploit the power-of-two nature of the second argument of ROUND_UP(), we still need to ensure that the mask is as wide as the first argument (done by using addition of 0 to force proper arithmetic promotion). Unpatched, ROUND_UP(2ULL*1024*1024*1024*1024, 512)

Re: [Qemu-block] [PATCH] rbd: Detect rbd image resizes and propagate them

On 09/13/2017 12:44 PM, Adam Wolfe Gordon wrote: > Register a watcher with rbd so that we get notified when an image is > resized. Propagate resizes to parent block devices so that guest devices > get resized without user intervention. > > Signed-off-by: Adam Wolfe Gordon

Re: [Qemu-block] [Qemu-devel] [PATCH v4 21/23] block: Align block status requests

On 09/13/2017 02:26 PM, Eric Blake wrote: > On 09/13/2017 11:03 AM, Eric Blake wrote: >> Any device that has request_alignment greater than 512 should be >> unable to report status at a finer granularity; it may also be >> simpler for such devices to be guaranteed that the block layer >> has

Re: [Qemu-block] [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them

Hi, This series failed build test on s390x host. Please find the details below. Subject: [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them Message-id: 20170913164424.32129-1-...@digitalocean.com Type: series === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be

Re: [Qemu-block] [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH] rbd: Detect rbd image resizes and propagate them Message-id: 20170913164424.32129-1-...@digitalocean.com Type: series === TEST SCRIPT BEGIN === #!/bin/bash BASE=base

[Qemu-block] [PATCH] rbd: Detect rbd image resizes and propagate them

Register a watcher with rbd so that we get notified when an image is resized. Propagate resizes to parent block devices so that guest devices get resized without user intervention. Signed-off-by: Adam Wolfe Gordon --- Hello! We are using this patch in production at

Re: [Qemu-block] [Qemu-devel] [PATCH v4 21/23] block: Align block status requests

On 09/13/2017 11:03 AM, Eric Blake wrote: > Any device that has request_alignment greater than 512 should be > unable to report status at a finer granularity; it may also be > simpler for such devices to be guaranteed that the block layer > has rounded things out to the granularity boundary (the

Re: [Qemu-block] [PATCH] block: Clean up some bad code in the vvfat driver

On 09/13/2017 06:21 AM, Thomas Huth wrote: > Remove the unnecessary home-grown redefinition of the assert() macro here, > and remove the unusable debug code at the end of the checkpoint() function. > The code there uses assert() with side-effects (assignment to the "mapping" > variable), which

[Qemu-block] [PATCH 17/18] qemu-io: Add background write

Add a new parameter -B to qemu-io's write command. When used, qemu-io will not wait for the result of the operation and instead execute it in the background. Signed-off-by: Max Reitz --- qemu-io-cmds.c | 83 +- 1 file

[Qemu-block] [PATCH 15/18] block/mirror: Add active mirroring

This patch implements active synchronous mirroring. In active mode, the passive mechanism will still be in place and is used to copy all initially dirty clusters off the source disk; but every write request will write data both to the source and the target disk, so the source cannot be dirtied

[Qemu-block] [PATCH 18/18] iotests: Add test for active mirroring

Signed-off-by: Max Reitz --- tests/qemu-iotests/151 | 111 + tests/qemu-iotests/151.out | 5 ++ tests/qemu-iotests/group | 1 + 3 files changed, 117 insertions(+) create mode 100755 tests/qemu-iotests/151 create mode

[Qemu-block] [PATCH 16/18] block/mirror: Add copy mode QAPI interface

This patch allows the user to specify whether to use active or only passive mode for mirror block jobs. Currently, this setting will remain constant for the duration of the entire block job. Signed-off-by: Max Reitz --- qapi/block-core.json | 11 +--

[Qemu-block] [PATCH 14/18] block/mirror: Distinguish active from passive ops

Currently, the mirror block job only knows passive operations. But once we introduce active writes, we need to distinguish between the two; for example, mirror_wait_for_free_in_flight_slot() should wait for a passive operation because active writes will not use the same in-flight slots.

[Qemu-block] [PATCH 13/18] block/mirror: Keep write perm for pending writes

The owner of the mirror BDS might retire its write permission; but there may still be pending mirror operations so the mirror BDS cannot necessarily retire its write permission for its child then. Signed-off-by: Max Reitz --- block/mirror.c | 6 -- 1 file changed, 4

[Qemu-block] [PATCH 12/18] block/dirty-bitmap: Add bdrv_dirty_iter_next_area

This new function allows to look for a consecutively dirty area in a dirty bitmap. Signed-off-by: Max Reitz --- include/block/dirty-bitmap.h | 2 ++ block/dirty-bitmap.c | 52 2 files changed, 54 insertions(+) diff --git

[Qemu-block] [PATCH 11/18] hbitmap: Add @advance param to hbitmap_iter_next()

This new parameter allows the caller to just query the next dirty position without moving the iterator. Signed-off-by: Max Reitz --- include/qemu/hbitmap.h | 4 +++- block/dirty-bitmap.c | 2 +- tests/test-hbitmap.c | 26 +- util/hbitmap.c

[Qemu-block] [PATCH 09/18] block: Generalize should_update_child() rule

Currently, bdrv_replace_node() refuses to create loops from one BDS to itself if the BDS to be replaced is the backing node of the BDS to replace it: Say there is a node A and a node B. Replacing B by A means making all references to B point to A. If B is a child of A (i.e. A has a reference to

[Qemu-block] [PATCH 06/18] block/mirror: Use CoQueue to wait on in-flight ops

Attach a CoQueue to each in-flight operation so if we need to wait for any we can use it to wait instead of just blindly yielding and hoping for some operation to wake us. A later patch will use this infrastructure to allow requests accessing the same area of the virtual disk to specifically wait

[Qemu-block] [PATCH 10/18] block/mirror: Make source the file child

Regarding the source BDS, the mirror BDS is arguably a filter node. Therefore, the source BDS should be its "file" child. Signed-off-by: Max Reitz --- block/mirror.c | 127 ++--- block/qapi.c | 25 ++---

[Qemu-block] [PATCH 05/18] block/mirror: Convert to coroutines

In order to talk to the source BDS (and maybe in the future to the target BDS as well) directly, we need to convert our existing AIO requests into coroutine I/O requests. Signed-off-by: Max Reitz --- block/mirror.c | 134

[Qemu-block] [PATCH 03/18] blockjob: Make drained_{begin, end} public

When a block job decides to be represented as a BDS and track its associated child nodes itself instead of having the BlockJob object track them, it needs to implement the drained_begin/drained_end child operations. In order to do that, it has to be able to control drainage of the block job (i.e.

[Qemu-block] [PATCH 07/18] block/mirror: Wait for in-flight op conflicts

This patch makes the mirror code differentiate between simply waiting for any operation to complete (mirror_wait_for_free_in_flight_slot()) and specifically waiting for all operations touching a certain range of the virtual disk to complete (mirror_wait_on_conflicts()). Signed-off-by: Max Reitz

[Qemu-block] [PATCH 04/18] block/mirror: Pull out mirror_perform()

When converting mirror's I/O to coroutines, we are going to need a point where these coroutines are created. mirror_perform() is going to be that point. Signed-off-by: Max Reitz --- block/mirror.c | 53 ++--- 1 file changed, 30

[Qemu-block] [PATCH 02/18] block: BDS deletion during bdrv_drain_recurse

Drainined a BDS child may lead to both the original BDS and/or its other children being deleted (e.g. if the original BDS represents a block job). We should prepare for this in both bdrv_drain_recurse() and bdrv_drained_begin() by monitoring whether the BDS we are about to drain still exists at

[Qemu-block] [PATCH 01/18] block: Add BdrvDeletedStatus

Sometimes an operation may delete a BDS. It may then not be trivial to determine this because the BDS object itself cannot be accessed afterwards. With this patch, one can attach a BdrvDeletedStatus object to a BDS which can be used to safely query whether the BDS still exists even after it has

[Qemu-block] [PATCH 00/18] block/mirror: Add active-sync mirroring

This series implements an active and synchronous mirroring mode. Currently, the mirror block job is passive an asynchronous: Depending on your start conditions, some part of the source disk starts as "dirty". Then, the block job will (as a background operation) continuously copy dirty parts to

Re: [Qemu-block] [Qemu-devel] [PATCH] throttle: Assert that bkt->max is valid in throttle_compute_wait()

Hi Alberto, On 09/13/2017 05:28 AM, Alberto Garcia wrote: If bkt->max == 0 and bkt->burst_length > 1 then we could have a division by 0 in throttle_do_compute_wait(). That configuration is however not permitted and is already detected by throttle_is_valid(), but let's assert it in

[Qemu-block] [PATCH v4 20/23] qemu-img: Change img_compare() to be byte-based

In the continuing quest to make more things byte-based, change the internal iteration of img_compare(). We can finally drop the TODO assertion added earlier, now that the entire algorithm is byte-based and no longer has to shift from bytes to sectors. Most of the change is mechanical

[Qemu-block] [PATCH v4 21/23] block: Align block status requests

Any device that has request_alignment greater than 512 should be unable to report status at a finer granularity; it may also be simpler for such devices to be guaranteed that the block layer has rounded things out to the granularity boundary (the way the block layer already rounds all other I/O

[Qemu-block] [PATCH v4 22/23] block: Relax bdrv_aligned_preadv() assertion

Now that bdrv_is_allocated accepts non-aligned inputs, we can remove the TODO added in commit d6a644bb. Signed-off-by: Eric Blake --- v3: new patch [Kevin] --- block/io.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/block/io.c b/block/io.c

[Qemu-block] [PATCH v4 17/23] qemu-img: Change check_empty_sectors() to byte-based

Continue on the quest to make more things byte-based instead of sector-based. Signed-off-by: Eric Blake --- v3: new patch --- qemu-img.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/qemu-img.c b/qemu-img.c index

[Qemu-block] [PATCH v4 19/23] qemu-img: Change img_rebase() to be byte-based

In the continuing quest to make more things byte-based, change the internal iteration of img_rebase(). We can finally drop the TODO assertion added earlier, now that the entire algorithm is byte-based and no longer has to shift from bytes to sectors. Most of the change is mechanical

[Qemu-block] [PATCH v4 23/23] qemu-io: Relax 'alloc' now that block-status doesn't assert

Previously, the alloc command required that input parameters be sector-aligned and clamped to 32 bits, because the underlying bdrv_is_allocated used a 32-bit parameter and asserted aligned inputs. But now that we have fixed block status to report a 64-bit bytes value, and to properly round

[Qemu-block] [PATCH v4 18/23] qemu-img: Change compare_sectors() to be byte-based

In the continuing quest to make more things byte-based, change compare_sectors(), renaming it to compare_buffers() in the process. Note that one caller (qemu-img compare) only cares about the first difference, while the other (qemu-img rebase) cares about how many consecutive sectors have the

[Qemu-block] [PATCH v4 15/23] qemu-img: Add find_nonzero()

During 'qemu-img compare', when we are checking that an allocated portion of one file is all zeros, we don't need to waste time computing how many additional sectors after the first non-zero byte are also non-zero. Create a new helper find_nonzero() to do the check for a first non-zero sector,

[Qemu-block] [PATCH v4 14/23] qemu-img: Speed up compare on pre-allocated larger file

Compare the following images with all-zero contents: $ truncate --size 1M A $ qemu-img create -f qcow2 -o preallocation=off B 1G $ qemu-img create -f qcow2 -o preallocation=metadata C 1G On my machine, the difference is noticeable for pre-patch speeds, with more than an order of magnitude in

[Qemu-block] [PATCH v4 13/23] qemu-img: Simplify logic in img_compare()

As long as we are querying the status for a chunk smaller than the known image size, we are guaranteed that a successful return will have set pnum to a non-zero size (pnum is zero only for queries beyond the end of the file). Use that to slightly simplify the calculation of the current chunk size

[Qemu-block] [PATCH v4 04/23] qcow2: Switch is_zero_sectors() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change), and rename it to is_zero() in the process. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-block] [PATCH v4 09/23] block: Switch BdrvCoGetBlockStatusData to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal type (no semantic change), and rename it to match the corresponding public function rename. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-block] [PATCH v4 12/23] block: Convert bdrv_get_block_status_above() to bytes

We are gradually moving away from sector-based interfaces, towards byte-based. In the common case, allocation is unlikely to ever use values that are not naturally sector-aligned, but it is possible that byte-based values will let us be more precise about allocation at the end of an unaligned

[Qemu-block] [PATCH v4 10/23] block: Switch bdrv_common_block_status_above() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change). Signed-off-by: Eric Blake Reviewed-by: Fam Zheng --- v3: rebase to allocation/mapping sense

[Qemu-block] [PATCH v4 16/23] qemu-img: Drop redundant error message in compare

If a read error is encountered during 'qemu-img compare', we were printing the "Error while reading offset ..." message twice. Update the testsuite for the improved output. Further simplify the code by hoisting the error code conversion into the helper function, rather than repeating it at the

[Qemu-block] [PATCH v4 08/23] block: Switch bdrv_co_get_block_status() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal function (no semantic change); and as with its public counterpart, rename to bdrv_co_block_status() to make the compiler enforce that we catch all uses. For now,

[Qemu-block] [PATCH v4 05/23] block: Switch bdrv_make_zero() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Change the internal loop iteration of zeroing a device to track by bytes instead of sectors (although we are still guaranteed that we iterate by steps that are sector-aligned).

[Qemu-block] [PATCH v4 02/23] block: Add flag to avoid wasted work in bdrv_is_allocated()

Not all callers care about which BDS owns the mapping for a given range of the file. In particular, bdrv_is_allocated() cares more about finding the largest run of allocated data from the guest perspective, whether or not that data is consecutive from the host perspective. Therefore, doing

[Qemu-block] [PATCH v4 01/23] block: Allow NULL file for bdrv_get_block_status()

Not all callers care about which BDS owns the mapping for a given range of the file. This patch merely simplifies the callers by consolidating the logic in the common call point, while guaranteeing a non-NULL file to all the driver callbacks, for no semantic change. The only caller that does not

[Qemu-block] [PATCH v4 11/23] block: Switch bdrv_co_get_block_status_above() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Convert another internal type (no semantic change), and rename it to match the corresponding public function rename. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-block] [PATCH v4 06/23] qemu-img: Switch get_block_status() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Continue by converting an internal function (no semantic change), and simplifying its caller accordingly. Signed-off-by: Eric Blake Reviewed-by: Fam Zheng

[Qemu-block] [PATCH v4 07/23] block: Convert bdrv_get_block_status() to bytes

We are gradually moving away from sector-based interfaces, towards byte-based. In the common case, allocation is unlikely to ever use values that are not naturally sector-aligned, but it is possible that byte-based values will let us be more precise about allocation at the end of an unaligned

[Qemu-block] [PATCH v4 03/23] block: Make bdrv_round_to_clusters() signature more useful

In the process of converting sector-based interfaces to bytes, I'm finding it easier to represent a byte count as a 64-bit integer at the block layer (even if we are internally capped by SIZE_MAX or even INT_MAX for individual transactions, it's still nicer to not have to worry about

[Qemu-block] [PATCH v4 00/23] make bdrv_get_block_status byte-based

There are patches floating around to add NBD_CMD_BLOCK_STATUS, but NBD wants to report status on byte granularity (even if the reporting will probably be naturally aligned to sectors or even much higher levels). I've therefore started the task of converting our block status code to report at a

Re: [Qemu-block] [PATCH v2 1/3] iotests: use -ccw on s390x for 040, 139, and 182

On 13.09.2017 11:10, Cornelia Huck wrote: > The default cpu model on s390x does not provide zPCI, which is > not yet wired up on tcg. Moreover, virtio-ccw is the standard > on s390x, so use the -ccw instead of the -pci versions of virtio > devices on s390x. > > Reviewed-by: Kevin Wolf

Re: [Qemu-block] [PATCH v2 3/3] iotests: use virtio aliases for 067

On 13.09.2017 11:10, Cornelia Huck wrote: > The default cpu model on s390x does not provide zPCI, which is > not yet wired up on tcg. Moreover, virtio-ccw is the standard > on s390x. > > Using virtio-scsi will implicitly pick the right device, so just > switch to that for simplicity. > >

Re: [Qemu-block] [PATCH v2 2/3] iotests: use -ccw on s390x for 051

On 13.09.2017 11:10, Cornelia Huck wrote: > The default cpu model on s390x does not provide zPCI, which is > not yet wired up on tcg. Moreover, virtio-ccw is the standard > on s390x, so use the -ccw instead of the -pci versions of virtio > devices on s390x. > > Signed-off-by: Cornelia Huck

Re: [Qemu-block] [Qemu-devel] Q: Report of leaked clusters with qcow2 when disk is resized with a live VM

Am 13.09.2017 um 15:32 hat Darren Kenny geschrieben: > Hi Kevin, > > Thanks for getting back to me so quickly. > > Kevin Wolf wrote: > > Am 13.09.2017 um 14:00 hat Darren Kenny geschrieben: > > > [Cross-posted from qemu-devel, meant to send here first] > > > > Just keep both lists in the CC for

Re: [Qemu-block] [Qemu-devel] [PATCH] throttle: Assert that bkt->max is valid in throttle_compute_wait()

On 09/13/2017 03:28 AM, Alberto Garcia wrote: > If bkt->max == 0 and bkt->burst_length > 1 then we could have a > division by 0 in throttle_do_compute_wait(). That configuration is > however not permitted and is already detected by throttle_is_valid(), > but let's assert it in

Re: [Qemu-block] [Qemu-devel] [PATCH] block: Clean up some bad code in the vvfat driver

On 09/13/2017 05:21 AM, Thomas Huth wrote: > Remove the unnecessary home-grown redefinition of the assert() macro here, > and remove the unusable debug code at the end of the checkpoint() function. > The code there uses assert() with side-effects (assignment to the "mapping" > variable), which

Re: [Qemu-block] [Qemu-devel] Q: Report of leaked clusters with qcow2 when disk is resized with a live VM

Hi Kevin, Thanks for getting back to me so quickly. Kevin Wolf wrote: Am 13.09.2017 um 14:00 hat Darren Kenny geschrieben: [Cross-posted from qemu-devel, meant to send here first] Just keep both lists in the CC for the same email. Will do. There is an issue here, which is that you are

Re: [Qemu-block] Q: Report of leaked clusters with qcow2 when disk is resized with a live VM

Am 13.09.2017 um 14:00 hat Darren Kenny geschrieben: > [Cross-posted from qemu-devel, meant to send here first] Just keep both lists in the CC for the same email. > Hi, > > It was observed during some testing of Qemu 2.9 that it appeared that if you > resized a qcow2 block device while the VM

[Qemu-block] Q: Report of leaked clusters with qcow2 when disk is resized with a live VM

[Cross-posted from qemu-devel, meant to send here first] Hi, It was observed during some testing of Qemu 2.9 that it appeared that if you resized a qcow2 block device while the VM is running, that an qemu-img check would report that there were leaked clusters. The steps to reproduce are:

[Qemu-block] [PATCH] block: Clean up some bad code in the vvfat driver

Remove the unnecessary home-grown redefinition of the assert() macro here, and remove the unusable debug code at the end of the checkpoint() function. The code there uses assert() with side-effects (assignment to the "mapping" variable), which should be avoided. Looking more closely, it seems as

[Qemu-block] [PATCH v2 3/3] iotests: use virtio aliases for 067

The default cpu model on s390x does not provide zPCI, which is not yet wired up on tcg. Moreover, virtio-ccw is the standard on s390x. Using virtio-scsi will implicitly pick the right device, so just switch to that for simplicity. Signed-off-by: Cornelia Huck ---

Re: [Qemu-block] [PATCH v2 2/3] iotests: use -ccw on s390x for 051

On 13.09.2017 11:10, Cornelia Huck wrote: > The default cpu model on s390x does not provide zPCI, which is > not yet wired up on tcg. Moreover, virtio-ccw is the standard > on s390x, so use the -ccw instead of the -pci versions of virtio > devices on s390x. > > Signed-off-by: Cornelia Huck

Re: [Qemu-block] [PATCH v2 3/3] iotests: use virtio aliases for 067

On 13.09.2017 11:10, Cornelia Huck wrote: > The default cpu model on s390x does not provide zPCI, which is > not yet wired up on tcg. Moreover, virtio-ccw is the standard > on s390x. > > Using virtio-scsi will implicitly pick the right device, so just > switch to that for simplicity. > >

[Qemu-block] [PATCH v2 2/3] iotests: use -ccw on s390x for 051

The default cpu model on s390x does not provide zPCI, which is not yet wired up on tcg. Moreover, virtio-ccw is the standard on s390x, so use the -ccw instead of the -pci versions of virtio devices on s390x. Signed-off-by: Cornelia Huck --- tests/qemu-iotests/051| 12

[Qemu-block] [PATCH v2 1/3] iotests: use -ccw on s390x for 040, 139, and 182

The default cpu model on s390x does not provide zPCI, which is not yet wired up on tcg. Moreover, virtio-ccw is the standard on s390x, so use the -ccw instead of the -pci versions of virtio devices on s390x. Reviewed-by: Kevin Wolf Signed-off-by: Cornelia Huck

[Qemu-block] [PATCH v2 0/3] iotests: cure s390x failures by switching to ccw/aliases

Recent changes in s390x made pci support dependant on the zpci cpu feature, which is not provided on all models (and not on by default). This means we cannot instatiate pci devices on a standard qemu invocation for s390x. Moreover, the zpci instructions are not even wired up for tcg yet, so

[Qemu-block] [PATCH] throttle: Assert that bkt->max is valid in throttle_compute_wait()

If bkt->max == 0 and bkt->burst_length > 1 then we could have a division by 0 in throttle_do_compute_wait(). That configuration is however not permitted and is already detected by throttle_is_valid(), but let's assert it in throttle_compute_wait() to make it explicit. Found by Coverity (CID:

Re: [Qemu-block] [Qemu-devel] [PATCH v2 00/10] cleanup qemu-iotests

On Wed, 09/13 08:47, Thomas Huth wrote: > Meta comment: Could we maybe also rename "tests/qemu-iotests" to > "tests/iotests" ? The "qemu" prefix sounds always very superfluous to me > here... Sounds good, and saves typing for when this path is manually entered. But maybe keep tests/qemu-iotests

Re: [Qemu-block] [Qemu-devel] [PATCH v7 28/38] libqtest: Add qtest_[v]startf()

On 12.09.2017 15:32, Eric Blake wrote: > On 09/12/2017 05:14 AM, Thomas Huth wrote: >> On 11.09.2017 19:20, Eric Blake wrote: >>> We have several callers that were formatting the argument strings >>> themselves; consolidate this effort by adding new convenience >>> functions directly in libqtest,

Re: [Qemu-block] [Qemu-devel] [PATCH v7 10/38] libqos: Move/rename qpci_unplug_acpi_device_test() to pci.c

On 12.09.2017 15:28, Eric Blake wrote: > On 09/12/2017 02:29 AM, Thomas Huth wrote: >> On 11.09.2017 19:19, Eric Blake wrote: >>> Commit 2f8b2767 originally added qpci_plug_device_test() and >>> qpci_unplug_acpi_device_test() as a pair, both in pci-pc.c. >>> Later, commit cf716b31 moved one half

Re: [Qemu-block] [Qemu-devel] [PATCH v7 09/38] libqos: Track QTestState with QVirtioBus

On 12.09.2017 15:28, Eric Blake wrote: > On 09/12/2017 02:21 AM, Thomas Huth wrote: [...] >> I fail to see why we need a separate bus object here for each device. >> The bus is only available one time, not multiple times, isn't it? So >> there should also only be one bus object floating around,

Re: [Qemu-block] [Qemu-devel] [PATCH v2 00/10] cleanup qemu-iotests

On 12.09.2017 16:44, Paolo Bonzini wrote: > The purpose of this series is to separate the "check" sources from > the tests. After these patches, common.config is reduced to simple > shell initialization, and common.rc is only included by the tests. > > Along the way, a lot of dead code is