Re: [Qemu-block] [PATCH v4 1/4] block: pass bdrv_* methods to bs->file by default in block filters

On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote: > The following functions fail if bs->drv is a filter and does not > implement them: > > bdrv_probe_blocksizes > bdrv_probe_geometry > bdrv_truncate > bdrv_has_zero_init > bdrv_get_info > > Instead, the call should be passed to bs->file if it

Re: [Qemu-block] [PATCH v4 2/4] block: remove bdrv_media_changed

On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote: > This function is not used anywhere, so remove it. > > Signed-off-by: Manos Pitsidianakis > --- > block.c | 14 -- > block/raw-format.c| 6 -- > include/block/block.h | 1 -

[Qemu-block] [PATCH v5 18/18] dirty-bitmap: Convert internal hbitmap size/granularity

Now that all callers are using byte-based interfaces, there's no reason for our internal hbitmap to remain with sector-based granularity. It also simplifies our internal scaling, since we already know that hbitmap widens requests out to granularity boundaries. Signed-off-by: Eric Blake

[Qemu-block] [PATCH v5 17/18] dirty-bitmap: Switch bdrv_set_dirty() to bytes

Both callers already had bytes available, but were scaling to sectors. Move the scaling to internal code. In the case of bdrv_aligned_pwritev(), we are now passing the exact offset rather than a rounded sector-aligned value, but that's okay as long as dirty bitmap widens start/bytes to

[Qemu-block] [PATCH v5 16/18] qcow2: Switch store_bitmap_data() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake Reviewed-by: John Snow --- v5: no change v4:

[Qemu-block] [PATCH v5 13/18] mirror: Switch mirror_dirty_init() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake --- v5: rebase to earlier changes v2-v4: no change ---

[Qemu-block] [PATCH v5 15/18] qcow2: Switch load_bitmap_data() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake Reviewed-by: John Snow --- v5: no change v4:

[Qemu-block] [PATCH v5 14/18] qcow2: Switch qcow2_measure() to byte-based iteration

This is new code, but it is easier to read if it makes passes over the image using bytes rather than sectors (and will get easier in the future when bdrv_get_block_status is converted to byte-based). While at it, fix a bug in the computation of nb_sectors using MAX rather than MIN and thus always

[Qemu-block] [PATCH v5 12/18] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

Some of the callers were already scaling bytes to sectors; others can be easily converted to pass byte offsets, all in our shift towards a consistent byte interface everywhere. Making the change will also make it easier to write the hold-out callers to use byte rather than sectors for their

[Qemu-block] [PATCH v5 11/18] dirty-bitmap: Change bdrv_get_dirty_locked() to take bytes

Half the callers were already scaling bytes to sectors; the other half can eventually be simplified to use byte iteration. Both callers were already using the result as a bool, so make that explicit. Making the change also makes it easier for a future dirty-bitmap patch to offload scaling over

[Qemu-block] [PATCH v5 05/18] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

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 dirty bitmap size in bytes, since it is (mostly) an

[Qemu-block] [PATCH v5 07/18] qcow2: Switch sectors_covered_by_bitmap_cluster() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Change the qcow2 bitmap helper function sectors_covered_by_bitmap_cluster(), renaming it to bytes_covered_by_bitmap_cluster() in the process. Signed-off-by: Eric Blake

[Qemu-block] [PATCH v5 10/18] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

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 Reviewed-by: Juan Quintela --- v4: no change v3: no change,

[Qemu-block] [PATCH v5 06/18] dirty-bitmap: Change bdrv_dirty_bitmap_*serialize*() to take bytes

Right now, the dirty-bitmap code exposes the fact that we use a scale of sector granularity in the underlying hbitmap to anything that wants to serialize a dirty bitmap. It's nicer to uniformly expose bytes as our dirty-bitmap interface, matching the previous change to bitmap size. The only

[Qemu-block] [PATCH v5 08/18] dirty-bitmap: Set iterator start by offset, not sector

All callers to bdrv_dirty_iter_new() passed 0 for their initial starting point, drop that parameter. Most callers to bdrv_set_dirty_iter() were scaling a byte offset to a sector number; the exception qcow2-bitmap will be converted later to use byte rather than sector iteration. Move the scaling

[Qemu-block] [PATCH v5 09/18] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

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 - in particular, there will be a few commits where we are temporarily relying on not-strict-C right-shift of -1 still resulting

[Qemu-block] [PATCH v5 02/18] hbitmap: Rename serialization_granularity to serialization_align

The only client of hbitmap_serialization_granularity() is dirty-bitmap's bdrv_dirty_bitmap_serialization_align(). Keeping the two names consistent is worthwhile, and the shorter name is more representative of what the function returns (the required alignment to be used for start/count of other

[Qemu-block] [PATCH v5 00/18] make dirty-bitmap 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

[Qemu-block] [PATCH v5 04/18] dirty-bitmap: Drop unused functions

We had several functions that no one is currently using, and which use sector-based interfaces. I'm trying to convert towards byte-based interfaces, so it's easier to just drop the unused functions: bdrv_dirty_bitmap_get_meta bdrv_dirty_bitmap_get_meta_locked bdrv_dirty_bitmap_reset_meta

[Qemu-block] [PATCH v5 03/18] qcow2: Ensure bitmap serialization is aligned

When subdividing a bitmap serialization, the code in hbitmap.c enforces that start/count parameters are aligned (except that count can end early at end-of-bitmap). We exposed this required alignment through bdrv_dirty_bitmap_serialization_align(), but forgot to actually check that we comply with

[Qemu-block] [PATCH v5 01/18] dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented

We've been documenting the value in bytes since its introduction in commit b9a9b3a4 (v1.3), where it was actually reported in bytes. Commit e4654d2 (v2.0) then removed things from block/qapi.c, in preparation for a rewrite to a list of dirty sectors in the next commit 21b5683 in block.c, but the

Re: [Qemu-block] [Qemu-devel] [PATCH v4 17/17] dirty-bitmap: Convert internal hbitmap size/granularity

On 07/12/2017 04:00 PM, John Snow wrote: > > > On 07/03/2017 11:10 AM, Eric Blake wrote: >> Now that all callers are using byte-based interfaces, there's no >> reason for our internal hbitmap to remain with sector-based >> granularity. It also simplifies our internal scaling, since we >>

Re: [Qemu-block] [Qemu-devel] [PATCH v4 17/17] dirty-bitmap: Convert internal hbitmap size/granularity

On 07/03/2017 11:10 AM, Eric Blake wrote: > Now that all callers are using byte-based interfaces, there's no > reason for our internal hbitmap to remain with sector-based > granularity. It also simplifies our internal scaling, since we > already know that hbitmap widens requests out to

Re: [Qemu-block] [Qemu-devel] [PATCH v4 15/17] qcow2: Switch store_bitmap_data() to byte-based iteration

On 07/03/2017 11:10 AM, Eric Blake wrote: > Now that we have adjusted the majority of the calls this function > makes to be byte-based, it is easier to read the code if it makes > passes over the image using bytes rather than sectors. > > Signed-off-by: Eric Blake >

Re: [Qemu-block] [Qemu-devel] [PATCH v4 14/17] qcow2: Switch load_bitmap_data() to byte-based iteration

On 07/03/2017 11:10 AM, Eric Blake wrote: > Now that we have adjusted the majority of the calls this function > makes to be byte-based, it is easier to read the code if it makes > passes over the image using bytes rather than sectors. > > Signed-off-by: Eric Blake >

Re: [Qemu-block] [Qemu-devel] [PATCH v4 12/17] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

On 07/03/2017 11:10 AM, Eric Blake wrote: > Some of the callers were already scaling bytes to sectors; others > can be easily converted to pass byte offsets, all in our shift > towards a consistent byte interface everywhere. Making the change > will also make it easier to write the hold-out

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

On 07/12/2017 01:00 PM, Max Reitz wrote: > On 2017-07-12 16:56, Kevin Wolf wrote: >> Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: >>> On 05/17/2017 07:38 AM, Max Reitz wrote: >>> >>> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 >>> >>> Or, rather,

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

On Wed, Jul 12, 2017 at 8:00 PM Max Reitz wrote: > On 2017-07-12 16:56, Kevin Wolf wrote: > > Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: > >> On 05/17/2017 07:38 AM, Max Reitz wrote: > >> > >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 >

Re: [Qemu-block] [Qemu-devel] [PATCH v14 15/21] qom: support non-scalar properties with -object

On Tue, Jul 11, 2017 at 03:49:50PM +0100, Daniel P. Berrange wrote: On Tue, Jul 11, 2017 at 04:44:46PM +0200, Markus Armbruster wrote: Markus Armbruster writes: > Manos Pitsidianakis writes: > >> Is there a specific reason this patch wasn't finished?

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

On 2017-07-12 16:56, Kevin Wolf wrote: > Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: >> On 05/17/2017 07:38 AM, Max Reitz wrote: >> >> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 >> >> Or, rather, force the open of a backing image if one was specified

Re: [Qemu-block] [PATCH v5 3/4] qcow2: add shrink image support

On 2017-07-12 16:52, Kevin Wolf wrote: > Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben: >> This patch add shrinking of the image file for qcow2. As a result, this >> allows >> us to reduce the virtual image size and free up space on the disk without >> copying the image. Image can be

Re: [Qemu-block] [PATCH 8/9] qemu-iotests: Test 'info block'

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > This test makes sure that all block devices show up on 'info block', > with all of the expected information, in different configurations. > > Signed-off-by: Kevin Wolf > --- > tests/qemu-iotests/186 | 147 ++ >

Re: [Qemu-block] [PATCH 9/9] qemu-iotests: Test unplug of -device without drive

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > This caused an assertion failure until recently because the BlockBackend > would be detached on unplug, but was in fact never attached in the first > place. Add a regression test. > > Signed-off-by: Kevin Wolf > --- >

Re: [Qemu-block] [PATCH 7/9] scsi-disk: bdrv_attach_dev() for empty CD-ROM

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > If no drive=... option is passed (for an empty drive), we don't only > lack the BlockBackend normally created by parse_drive(), but we also > need to manually call blk_attach_dev(). > > This fixes at least a segfault when unplugging such devices, the

Re: [Qemu-block] [PATCH 6/9] ide: bdrv_attach_dev() for empty CD-ROM

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > If no drive=... option is passed (for an empty drive), we don't only > lack the BlockBackend normally created by parse_drive(), but we also > need to manually call blk_attach_dev(). > > IDE does not support hot unplug, but if it did, qdev would take

Re: [Qemu-block] [PATCH 5/9] block: List anonymous device BBs in query-block

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > Instead of listing only monitor-owned BlockBackends in query-block, also > add those anonymous BlockBackends that are owned by a qdev device and as > such under the control of the user. > > This allows to use query-block to inspect BlockBackends for the

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/4] block: remove bdrv_media_changed

On Wed, Jul 12, 2017 at 05:15:01PM +0200, Kevin Wolf wrote: Am 12.07.2017 um 09:41 hat Markus Armbruster geschrieben: Eric Blake writes: > On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote: >> This function is not used anywhere, so remove it. >> > > Might be interesting to

Re: [Qemu-block] [Qemu-devel] [PATCH v4 0/4] block: Block driver callbacks fixes

Am 12.07.2017 um 10:10 hat Manos Pitsidianakis geschrieben: > On Wed, Jul 12, 2017 at 09:49:20AM +0200, Markus Armbruster wrote: > >Manos Pitsidianakis writes: > > > >>This series makes implementing some of the bdrv_* callbacks easier for block > >>filters by passing

Re: [Qemu-block] [PATCH 4/9] block/qapi: Use blk_all_next() for query-block

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > This patch replaces the blk_next() loop in query-block by a > blk_all_next() one so that we also get access to BlockBackends that > aren't owned by the monitor. For now, the next thing we do is check > whether each BB has a name, so there is no

Re: [Qemu-block] [PATCH 3/9] block: Make blk_all_next() public

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > Signed-off-by: Kevin Wolf > --- > block/block-backend.c | 2 +- > include/sysemu/block-backend.h | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Eric Blake (although the commit

Re: [Qemu-block] [PATCH v3 1/3] block: add bdrv_get_format_alloc_stat format interface

30.06.2017 03:27, John Snow wrote: On 06/06/2017 12:26 PM, Vladimir Sementsov-Ogievskiy wrote: The function should collect statistics, about used/unused by top-level format driver space (in its .file) and allocation status (data/zero/discarded/after-eof) of corresponding areas in this .file.

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/4] block: remove bdrv_media_changed

Am 12.07.2017 um 09:41 hat Markus Armbruster geschrieben: > Eric Blake writes: > > > On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote: > >> This function is not used anywhere, so remove it. > >> > > > > Might be interesting to figure out when it WAS last used. > > Yes.

Re: [Qemu-block] [PATCH 2/9] block/qapi: Add qdev device name to query-block

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > With -blockdev/-device, users can indirectly create anonymous > BlockBackends, in the state of which they are still interested. As a Reads awkwardly. Maybe: BlockBackends, although it is still of interest to learn the state of such backends. >

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

Am 12.07.2017 um 16:42 hat Eric Blake geschrieben: > On 05/17/2017 07:38 AM, Max Reitz wrote: > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 > > Or, rather, force the open of a backing image if one was specified > for creation. Using a similar

Re: [Qemu-block] [PATCH 1/9] block: Make blk_get_attached_dev_id() public

On 07/12/2017 07:57 AM, Kevin Wolf wrote: > Signed-off-by: Kevin Wolf > --- > block/block-backend.c | 3 +-- > include/sysemu/block-backend.h | 1 + > 2 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Eric Blake -- Eric Blake,

Re: [Qemu-block] [PATCH v5 3/4] qcow2: add shrink image support

Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben: > This patch add shrinking of the image file for qcow2. As a result, this allows > us to reduce the virtual image size and free up space on the disk without > copying the image. Image can be fragmented and shrink is done by punching > holes >

Re: [Qemu-block] [PATCH v5 2/4] qcow2: add qcow2_cache_discard

Am 12.07.2017 um 13:46 hat Pavel Butsykin geschrieben: > Whenever l2/refcount table clusters are discarded from the file we can > automatically drop unnecessary content of the cache tables. This reduces > the chance of eviction useful cache data and eliminates inconsistent data > in the cache with

Re: [Qemu-block] [PATCH v4] qemu-img: Check for backing image if specified during create

On 05/17/2017 07:38 AM, Max Reitz wrote: Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 Or, rather, force the open of a backing image if one was specified for creation. Using a similar -unsafe option as rebase, allow qemu-img to ignore the

Re: [Qemu-block] Supporting unsafe create when backing file is not accessible

On 07/12/2017 03:56 AM, Ala Hino wrote: > Hi, > > We encountered a performance issue when creating a volume for a running VM > and we'd like to share the info with you. The root cause of the issue is in > our code but we found a workaround that relies on qemu-img create > undocumented behavior. >

Re: [Qemu-block] [PATCH v5 0/4] Add shrink image for qcow2

On 2017-07-12 13:46, Pavel Butsykin wrote: > This patch add shrinking of the image file for qcow2. As a result, this allows > us to reduce the virtual image size and free up space on the disk without > copying the image. Image can be fragmented and shrink is done by punching > holes > in the

Re: [Qemu-block] [PATCH v3 3/6] block: Introduce bdrv_dma_map and bdrv_dma_unmap

On 12/07/2017 03:07, Fam Zheng wrote: > On Tue, 07/11 12:28, Paolo Bonzini wrote: >> On 11/07/2017 12:05, Stefan Hajnoczi wrote: >>> On Mon, Jul 10, 2017 at 05:08:56PM +0200, Paolo Bonzini wrote: On 10/07/2017 17:07, Stefan Hajnoczi wrote: > On Wed, Jul 05, 2017 at 09:36:32PM +0800, Fam

[Qemu-block] [PATCH 3/9] block: Make blk_all_next() public

Signed-off-by: Kevin Wolf --- block/block-backend.c | 2 +- include/sysemu/block-backend.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/block/block-backend.c b/block/block-backend.c index d60e53b..15072f8 100644 --- a/block/block-backend.c +++

[Qemu-block] [PATCH 1/9] block: Make blk_get_attached_dev_id() public

Signed-off-by: Kevin Wolf --- block/block-backend.c | 3 +-- include/sysemu/block-backend.h | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/block-backend.c b/block/block-backend.c index 0df3457..d60e53b 100644 --- a/block/block-backend.c +++

[Qemu-block] [PATCH 6/9] ide: bdrv_attach_dev() for empty CD-ROM

If no drive=... option is passed (for an empty drive), we don't only lack the BlockBackend normally created by parse_drive(), but we also need to manually call blk_attach_dev(). IDE does not support hot unplug, but if it did, qdev would take care to call the matching blk_detach_dev() on unplug.

[Qemu-block] [PATCH 7/9] scsi-disk: bdrv_attach_dev() for empty CD-ROM

If no drive=... option is passed (for an empty drive), we don't only lack the BlockBackend normally created by parse_drive(), but we also need to manually call blk_attach_dev(). This fixes at least a segfault when unplugging such devices, the bug that they didn't show up in query-block, and

[Qemu-block] [PATCH 9/9] qemu-iotests: Test unplug of -device without drive

This caused an assertion failure until recently because the BlockBackend would be detached on unplug, but was in fact never attached in the first place. Add a regression test. Signed-off-by: Kevin Wolf --- tests/qemu-iotests/067 | 13 +

[Qemu-block] [PATCH 8/9] qemu-iotests: Test 'info block'

This test makes sure that all block devices show up on 'info block', with all of the expected information, in different configurations. Signed-off-by: Kevin Wolf --- tests/qemu-iotests/186 | 147 ++ tests/qemu-iotests/186.out | 489

[Qemu-block] [PATCH 0/9] block: -device drive= fixes

Since 2.9 it is possible for a user to care only about nodes and qdev devices, but not about BlockBackends, by defining with -blockdev and using their node name in -device. Devices create an anonymous BlockBackend internally then. One of the major problems in this setup is that such devices are

[Qemu-block] [PATCH 5/9] block: List anonymous device BBs in query-block

Instead of listing only monitor-owned BlockBackends in query-block, also add those anonymous BlockBackends that are owned by a qdev device and as such under the control of the user. This allows to use query-block to inspect BlockBackends for the modern configuration syntax with -blockdev and

[Qemu-block] [PATCH 2/9] block/qapi: Add qdev device name to query-block

With -blockdev/-device, users can indirectly create anonymous BlockBackends, in the state of which they are still interested. As a preparation for making such BBs visible in query-block, make sure that they can be identified even without a name by adding the ID/QOM path of their qdev device to

[Qemu-block] [PATCH 4/9] block/qapi: Use blk_all_next() for query-block

This patch replaces the blk_next() loop in query-block by a blk_all_next() one so that we also get access to BlockBackends that aren't owned by the monitor. For now, the next thing we do is check whether each BB has a name, so there is no semantical difference. Signed-off-by: Kevin Wolf

[Qemu-block] [PATCH v5 4/4] qemu-iotests: add shrinking image test

Signed-off-by: Pavel Butsykin Reviewed-by: Max Reitz --- tests/qemu-iotests/163 | 170 + tests/qemu-iotests/163.out | 5 ++ tests/qemu-iotests/group | 1 + 3 files changed, 176 insertions(+)

[Qemu-block] [PATCH v5 2/4] qcow2: add qcow2_cache_discard

Whenever l2/refcount table clusters are discarded from the file we can automatically drop unnecessary content of the cache tables. This reduces the chance of eviction useful cache data and eliminates inconsistent data in the cache with the data in the file. Signed-off-by: Pavel Butsykin

[Qemu-block] [PATCH v5 1/4] qemu-img: add --shrink flag for resize

The flag is additional precaution against data loss. Perhaps in the future the operation shrink without this flag will be blocked for all formats, but for now we need to maintain compatibility with raw. Signed-off-by: Pavel Butsykin Reviewed-by: Max Reitz

[Qemu-block] [PATCH v5 3/4] qcow2: add shrink image support

This patch add shrinking of the image file for qcow2. As a result, this allows us to reduce the virtual image size and free up space on the disk without copying the image. Image can be fragmented and shrink is done by punching holes in the image file. Signed-off-by: Pavel Butsykin

[Qemu-block] [PATCH v5 0/4] Add shrink image for qcow2

This patch add shrinking of the image file for qcow2. As a result, this allows us to reduce the virtual image size and free up space on the disk without copying the image. Image can be fragmented and shrink is done by punching holes in the image file. # ./qemu-img create -f qcow2 image.qcow2 4G

[Qemu-block] Supporting unsafe create when backing file is not accessible

Hi, We encountered a performance issue when creating a volume for a running VM and we'd like to share the info with you. The root cause of the issue is in our code but we found a workaround that relies on qemu-img create undocumented behavior. During our tests, we found that in order to create a

Re: [Qemu-block] [PATCH v3 2/6] block: Add VFIO based NVMe driver

On Wed, Jul 12, 2017 at 10:14:48AM +0800, Fam Zheng wrote: > On Mon, 07/10 15:55, Stefan Hajnoczi wrote: > > On Wed, Jul 05, 2017 at 09:36:31PM +0800, Fam Zheng wrote: > > > +static int nvme_co_prw(BlockDriverState *bs, uint64_t offset, uint64_t > > > bytes, > > > +

Re: [Qemu-block] [PATCH 11/11] block/snapshot: do not take AioContext lock

On Tue, Jul 11, 2017 at 11:48:02AM +0200, Paolo Bonzini wrote: > On 11/07/2017 11:43, Stefan Hajnoczi wrote: > >>> > >>> 1. Must be called under BQL? > >>> 2. Can I/O requests be in flight? > >>> 3. Is it thread-safe? > >>> > >>> Otherwise it will be a nightmare to modify the code since these >

Re: [Qemu-block] [PATCH v4 4/4] block: add default implementations for bdrv_co_get_block_status()

On Tue, Jul 11, 2017 at 07:37:48PM +0300, Manos Pitsidianakis wrote: > bdrv_co_get_block_status_from_file() and > bdrv_co_get_block_status_from_backing() set *file to bs->file and > bs->backing respectively, so that bdrv_co_get_block_status() can recurse > to them. Future block drivers won't have

Re: [Qemu-block] [PATCH v4 3/4] block: remove bdrv_truncate callback in blkdebug

On Tue, Jul 11, 2017 at 07:37:47PM +0300, Manos Pitsidianakis wrote: > Now that bdrv_truncate is passed to bs->file by default, remove the > callback from block/blkdebug.c and set is_filter to true. > > Signed-off-by: Manos Pitsidianakis > --- > block/blkdebug.c | 7

Re: [Qemu-block] [PATCH v4 1/4] block: pass bdrv_* methods to bs->file by default in block filters

On Tue, Jul 11, 2017 at 07:37:45PM +0300, Manos Pitsidianakis wrote: > The following functions fail if bs->drv is a filter and does not > implement them: > > bdrv_probe_blocksizes > bdrv_probe_geometry > bdrv_truncate > bdrv_has_zero_init > bdrv_get_info > > Instead, the call should be passed to

Re: [Qemu-block] [PATCH v4 2/4] block: remove bdrv_media_changed

On Tue, Jul 11, 2017 at 07:37:46PM +0300, Manos Pitsidianakis wrote: > This function is not used anywhere, so remove it. > > Signed-off-by: Manos Pitsidianakis > --- > block.c | 14 -- > block/raw-format.c| 6 -- >

Re: [Qemu-block] [PATCH v2] block: fix leaks in bdrv_open_driver()

On Wed, Jul 12, 2017 at 10:33:37AM +0200, Kevin Wolf wrote: Am 11.07.2017 um 20:50 hat Manos Pitsidianakis geschrieben: On Tue, Jul 11, 2017 at 05:16:17PM +0200, Kevin Wolf wrote: >Am 01.07.2017 um 17:39 hat Manos Pitsidianakis geschrieben: >>bdrv_open_driver() is called in two places,

Re: [Qemu-block] [PATCH v2] block: fix leaks in bdrv_open_driver()

Am 11.07.2017 um 20:50 hat Manos Pitsidianakis geschrieben: > On Tue, Jul 11, 2017 at 05:16:17PM +0200, Kevin Wolf wrote: > >Am 01.07.2017 um 17:39 hat Manos Pitsidianakis geschrieben: > >>bdrv_open_driver() is called in two places, bdrv_new_open_driver() and > >>bdrv_open_common(). In the latter,

Re: [Qemu-block] [Qemu-devel] [PATCH v4 0/4] block: Block driver callbacks fixes

On Wed, Jul 12, 2017 at 09:49:20AM +0200, Markus Armbruster wrote: Manos Pitsidianakis writes: This series makes implementing some of the bdrv_* callbacks easier for block filters by passing requests to bs->file if bs->drv doesn't implement it instead of failing, and

Re: [Qemu-block] [Qemu-devel] [PATCH v4 0/4] block: Block driver callbacks fixes

Manos Pitsidianakis writes: > This series makes implementing some of the bdrv_* callbacks easier for block > filters by passing requests to bs->file if bs->drv doesn't implement it > instead > of failing, and adding default bdrv_co_get_block_status() implementations. > >

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/4] block: remove bdrv_media_changed

Eric Blake writes: > On 07/11/2017 11:37 AM, Manos Pitsidianakis wrote: >> This function is not used anywhere, so remove it. >> > > Might be interesting to figure out when it WAS last used. Yes. When I see "remove X because it's unused" during patch review, I immediately