Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/1] block: clarify error message for qmp-eject

On 05/20/2016 10:48 AM, Markus Armbruster wrote: > John Snow writes: > >> If you use HMP's eject but the CDROM tray is locked, you may get a >> confusing error message informing you that the "tray isn't open." >> >> As this is the point of eject, we can do a little better and

[Qemu-block] [PATCH v7 09/15] block: Simplify drive-mirror

Now that we can support boxed commands, use it to greatly reduce the number of parameters (and likelihood of getting out of sync) when adjusting drive-mirror parameters. Signed-off-by: Eric Blake --- v7: new patch --- qapi/block-core.json | 17 - blockdev.c

[Qemu-block] [PATCH v7 08/15] block: Simplify block_set_io_throttle

Now that we can support boxed commands, use it to greatly reduce the number of parameters (and likelihood of getting out of sync) when adjusting throttle parameters. Signed-off-by: Eric Blake --- v7: new patch --- qapi/block-core.json | 20 -- blockdev.c |

[Qemu-block] [PATCH v3] block: Fix bdrv_next() memory leak

The bdrv_next() users all leaked the BdrvNextIterator after completing the iteration. Simply changing bdrv_next() to free the iterator before returning NULL at the end of list doesn't work because some callers exit the loop before looking at all BDSes. This patch moves the BdrvNextIterator from

[Qemu-block] [PATCH v2] block: Fix bdrv_next() memory leak

The bdrv_next() users all leaked the BdrvNextIterator after completing the iteration. Simply changing bdrv_next() to free the iterator before returning NULL at the end of list doesn't work because some callers exit the loop before looking at all BDSes. This patch moves the BdrvNextIterator from

Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/1] block: clarify error message for qmp-eject

John Snow writes: > If you use HMP's eject but the CDROM tray is locked, you may get a > confusing error message informing you that the "tray isn't open." > > As this is the point of eject, we can do a little better and help > clarify that the tray was locked and that it

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

On 20/05/2016 12:26, Kevin Wolf wrote: > Hm, we have a few instances where an iterator variable is used for > multiple loops, so we need to be able to use it in an assignment, i.e. > it should be a compound literal. On the other hand, I seem to remember > that compound literals can't be used as

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

Am 20.05.2016 um 11:39 hat Paolo Bonzini geschrieben: > > > On 20/05/2016 10:10, Kevin Wolf wrote: > >> > Already posted a fix. I chose to keep the interface and free the > >> > BdrvNextIterator inside bdrv_next(), when we return NULL after the last > >> > element. > > Oops, should have actually

[Qemu-block] [PATCH V2] block/iscsi: allow caching of the allocation map

until now the allocation map was used only as a hint if a cluster is allocated or not. If a block was not allocated (or Qemu had no info about the allocation status) a get_block_status call was issued to check the allocation status and possibly avoid a subsequent read of unallocated sectors. If a

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

On 20/05/2016 10:10, Kevin Wolf wrote: >> > Already posted a fix. I chose to keep the interface and free the >> > BdrvNextIterator inside bdrv_next(), when we return NULL after the last >> > element. > Oops, should have actually read your email... You're right about callers > that prematurely

[Qemu-block] Overflow in Virtio-BLK and SCSI Requests?

Hi, while working at the iSCSI code in Qemu I came across the following line in iscsi_aio_ioctl memcpy(>task->cdb[0], acb->ioh->cmdp, acb->ioh->cmd_len); Is there anything to ensure that the cmd_len is valid when the requests is e.g. coming in via virtio_blk_handle_scsi ? It seems that

Re: [Qemu-block] [PATCH] block: Fix memory leak in bdrv_next()

Am 20.05.2016 um 09:57 hat Kevin Wolf geschrieben: > When all BDSes have already been iterated and we return NULL, the > iterator must be freed, too. > > Signed-off-by: Kevin Wolf NACK, this doesn't fix cases where the caller exists loop prematurely. Kevin

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

Am 20.05.2016 um 10:05 hat Kevin Wolf geschrieben: > Am 20.05.2016 um 09:54 hat Paolo Bonzini geschrieben: > > > +/* Iterates over all top-level BlockDriverStates, i.e. BDSs that are > > > owned by > > > + * the monitor or attached to a BlockBackend */ > > > +BdrvNextIterator

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

Am 20.05.2016 um 09:54 hat Paolo Bonzini geschrieben: > > > On 19/05/2016 17:21, Kevin Wolf wrote: > > We need to introduce a separate BdrvNextIterator struct that can keep > > more state than just the current BDS in order to avoid using the bs->blk > > pointer. > > > > Signed-off-by: Kevin

Re: [Qemu-block] [PATCH 1/3] blockdev-backup: Don't move target AioContext if it's attached

Am 18.05.2016 um 10:24 hat Fam Zheng geschrieben: > If the BDS is attached, it will want to stay on the AioContext where its > BlockBackend is. Don't call bdrv_set_aio_context in this case. > > Signed-off-by: Fam Zheng > --- > blockdev.c | 12 +++- > 1 file changed, 11

[Qemu-block] [PATCH] block: Fix memory leak in bdrv_next()

When all BDSes have already been iterated and we return NULL, the iterator must be freed, too. Signed-off-by: Kevin Wolf --- block/block-backend.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/block/block-backend.c b/block/block-backend.c index

Re: [Qemu-block] [PULL 21/31] block: Avoid bs->blk in bdrv_next()

On 19/05/2016 17:21, Kevin Wolf wrote: > We need to introduce a separate BdrvNextIterator struct that can keep > more state than just the current BDS in order to avoid using the bs->blk > pointer. > > Signed-off-by: Kevin Wolf > Reviewed-by: Max Reitz >

[Qemu-block] [PATCH v19 06/10] auto complete active commit

From: Wen Congyang Auto complete mirror job in background to prevent from blocking synchronously Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- block/mirror.c| 13 + blockdev.c

[Qemu-block] [PATCH v19 04/10] Link backup into block core

From: Wen Congyang Some programs that add a dependency on it will use the block layer directly. Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by:

[Qemu-block] [PATCH v19 07/10] Introduce new APIs to do replication operation

Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- Makefile.objs| 1 + qapi/block-core.json | 13

[Qemu-block] [PATCH v19 03/10] Backup: export interfaces for extra serialization

Normal backup(sync='none') workflow: step 1. NBD peformance I/O write from client to server qcow2_co_writev bdrv_co_writev ... bdrv_aligned_pwritev notifier_with_return_list_notify -> backup_do_cow bdrv_driver_pwritev // write new contents step 2. drive-backup

[Qemu-block] [PATCH v19 08/10] Implement new driver for block replication

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- block/Makefile.objs | 1 +

[Qemu-block] [PATCH v19 01/10] unblock backup operations in backing file

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- block.c | 17 + 1 file changed, 17 insertions(+) diff --git a/block.c b/block.c index 1205ef8..8c4c2c2 100644 --- a/block.c

[Qemu-block] [PATCH v19 05/10] docs: block replication's description

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- docs/block-replication.txt |

[Qemu-block] [PATCH v19 10/10] support replication driver in blockdev-add

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie Reviewed-by: Eric Blake

[Qemu-block] [PATCH v19 02/10] Backup: clear all bitmap when doing block checkpoint

From: Wen Congyang Signed-off-by: Wen Congyang Signed-off-by: zhanghailiang Signed-off-by: Gonglei Signed-off-by: Changlong Xie --- block/backup.c |

[Qemu-block] [PATCH v19 00/10] Block replication for continuous checkpoints

Block replication is a very important feature which is used for continuous checkpoints(for example: COLO). You can get the detailed information about block replication from here: http://wiki.qemu.org/Features/BlockReplication Usage: Please refer to docs/block-replication.txt You can get the

[Qemu-block] [PATCH v19 09/10] tests: add unit test case for replication

Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie --- tests/.gitignore | 1 + tests/Makefile | 4 + tests/test-replication.c | 523 +++ 3 files changed, 528 insertions(+)