Re: [Qemu-block] [PATCH v3 19/22] block: Split bdrv_merge_limits() from bdrv_refresh_limits()

On Thu, 06/23 16:37, Eric Blake wrote: > During bdrv_merge_limits(), we were computing initial limits > based on another BDS in two places. At first glance, the two > computations are not identical (one is doing straight copying, > the other is doing merging towards or away from zero) - but > when

Re: [Qemu-block] [PATCH v3 18/22] block: Drop raw_refresh_limits()

On Thu, 06/23 16:37, Eric Blake wrote: > The raw block driver was blindly copying all limits from bs->file, > even though: 1. the main bdrv_refresh_limits() already does this > for many of the limits, and 2. blindly copying from the children > can weaken any stricter limits that were already inheri

Re: [Qemu-block] [PATCH 2/4] virtio: Always use aio path to set host handler

On 24/06/2016 07:12, Fam Zheng wrote: > Apart from the interface difference, the aio version works the same as > the non-aio one. The event notifier versus aio fd handler makes no > diffeerence, except the former led to an ugly patch in commit > ab27c3b5e7, which won't be necessary any more. > >

Re: [Qemu-block] [PATCH v3 16/22] block: Wording tweaks to write zeroes limits

On Thu, 06/23 16:37, Eric Blake wrote: > Improve the documentation of the write zeroes limits, to mention > additional constraints that drivers should observe. Worth squashing > into commit cf081fca, if that hadn't been pushed already :) > > Signed-off-by: Eric Blake > > --- > v3: new patch, sp

Re: [Qemu-block] [PATCH v3 17/22] block: Switch discard length bounds to byte-based

On Thu, 06/23 16:37, Eric Blake wrote: > Sector-based limits are awkward to think about; in our on-going > quest to move to byte-based interfaces, convert max_discard and > discard_alignment. Rename them, using 'pdiscard' as an aid to > track which remaining discard interfaces need conversion, and

Re: [Qemu-block] [PATCH v3 15/22] block: Switch transfer length bounds to byte-based

On Thu, 06/23 16:37, Eric Blake wrote: > Sector-based limits are awkward to think about; in our on-going > quest to move to byte-based interfaces, convert max_transfer_length > and opt_transfer_length. Rename them (dropping the _length suffix) > so that the compiler will help us catch the change i

[Qemu-block] [PULL 34/34] virtio-bus: remove old set_host_notifier callback

From: Cornelia Huck All users have been converted to the new ioevent callbacks. Signed-off-by: Cornelia Huck Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- include/hw/virtio/virtio-bus.h | 1 - hw/block/dataplane/

[Qemu-block] [PULL 30/34] virtio-bus: have callers tolerate new host notifier api

From: Cornelia Huck Have vhost and dataplane use the new api for transports that have been converted. Signed-off-by: Cornelia Huck Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin --- hw/block/dataplane/virtio-blk.c | 14

Re: [Qemu-block] [PATCH v3 09/22] blkdebug: Set request_alignment during .bdrv_refresh_limits()

On Thu, 06/23 16:37, Eric Blake wrote: > We want to eventually stick request_alignment alongside other > BlockLimits, but first, we must ensure it is populated at the > same time as all other limits, rather than being a special case > that is set only when a block is first opened. > > Note that wh

Re: [Qemu-block] [PATCH v3 08/22] block: Give nonzero result to blk_get_max_transfer_length()

On Thu, 06/23 16:37, Eric Blake wrote: > Making all callers special-case 0 as unlimited is awkward, > and we DO have a hard maximum of BDRV_REQUEST_MAX_SECTORS given > our current block layer API limits. > > In the case of scsi, this means that we now always advertise a > limit to the guest, even

Re: [Qemu-block] [PATCH v3 07/22] scsi: Advertise limits by blocksize, not 512

On Thu, 06/23 16:37, Eric Blake wrote: > s->blocksize may be larger than 512, in which case our > tweaks to max_xfer_len and opt_xfer_len must be scaled > appropriately. > > Reported-by: Fam Zheng > Signed-off-by: Eric Blake > CC: qemu-sta...@nongnu.org > > --- > v3: new patch > --- > hw/scsi/

[Qemu-block] [PATCH 1/4] virtio: Add typedef for handle_output

The function pointer signature has been repeated a few times, using a typedef may make coding easier. Signed-off-by: Fam Zheng --- hw/virtio/virtio.c | 9 - include/hw/virtio/virtio.h | 5 +++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/hw/virtio/virtio.c b/h

[Qemu-block] [PATCH 4/4] Revert "mirror: Workaround for unexpected iohandler events during completion"

This reverts commit ab27c3b5e7408693dde0b565f050aa55c4a1bcef. The virtio host notifiers are now covered by bdrv_drained_begin/end, so we don't need this hacky quiescing of the iohandler context anymore. Signed-off-by: Fam Zheng --- block/mirror.c | 9 - 1 file changed, 9 deletions(-) d

[Qemu-block] [PATCH 2/4] virtio: Always use aio path to set host handler

Apart from the interface difference, the aio version works the same as the non-aio one. The event notifier versus aio fd handler makes no diffeerence, except the former led to an ugly patch in commit ab27c3b5e7, which won't be necessary any more. As the first step to unify them, all callers are sw

[Qemu-block] [PATCH 3/4] virtio: Drop the unused virtio_queue_set_host_notifier_fd_handler code

Signed-off-by: Fam Zheng --- hw/virtio/virtio.c | 24 include/hw/virtio/virtio.h | 2 -- 2 files changed, 26 deletions(-) diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c index 99cd0c0..7a375c1 100644 --- a/hw/virtio/virtio.c +++ b/hw/virtio/virtio.c @@ -181

[Qemu-block] [PATCH 0/4] virtio: Merge two host notifier handling paths

This series is based on top of Cornelia's [PATCH 0/6] virtio: refactor host notifiers The benifit is we don't use event_notifier_set_handler even in non-dataplane now, which in turn makes virtio-blk and virtio-scsi follow block layer aio context semantics. Specifically, I/O requests must come

[Qemu-block] [PATCH 1/2] nbd: Convert to byte-based interface

The NBD protocol doesn't have any notion of sectors, so it is a fairly easy convertion to use byte-based read and write. Signed-off-by: Eric Blake --- block/nbd-client.h | 8 include/block/nbd.h | 1 - block/nbd-client.c | 30 +- block/nbd.c | 12

[Qemu-block] [PATCH 2/2] raw_bsd: Convert to byte-based interface

Since the raw format driver is just passing things through, we can do byte-based read and write if the underlying protocol does likewise. There's one tricky part - if we probed the image format, we document that we restrict operations on the initial sector. Rather than trying to handle a read-mod

[Qemu-block] [PATCH 0/2] Switch raw NBD to byte-based

With these two patches, I'm finally able to run: ./qemu-nbd -f raw -x foo file ./qemu-io -f raw -t none nbd://localhost:10809/foo and get true byte-based access over the wire for operations such as 'r 1 1' or 'w 1 1', rather than RMW sector-aligned access. Depends on these series: v3 Byte-based

[Qemu-block] [PATCH v3 19/22] block: Split bdrv_merge_limits() from bdrv_refresh_limits()

During bdrv_merge_limits(), we were computing initial limits based on another BDS in two places. At first glance, the two computations are not identical (one is doing straight copying, the other is doing merging towards or away from zero) - but when you realize that the first round is starting wit

[Qemu-block] [PATCH v3 18/22] block: Drop raw_refresh_limits()

The raw block driver was blindly copying all limits from bs->file, even though: 1. the main bdrv_refresh_limits() already does this for many of the limits, and 2. blindly copying from the children can weaken any stricter limits that were already inherited from the backing chain during the main bdrv

[Qemu-block] [PATCH v3 17/22] block: Switch discard length bounds to byte-based

Sector-based limits are awkward to think about; in our on-going quest to move to byte-based interfaces, convert max_discard and discard_alignment. Rename them, using 'pdiscard' as an aid to track which remaining discard interfaces need conversion, and so that the compiler will help us catch the ch

[Qemu-block] [PATCH v3 22/22] block: Use bool as appropriate for BDS members

Using int for values that are only used as booleans is confusing. While at it, rearrange a couple of members so that all the bools are contiguous. Signed-off-by: Eric Blake --- v3: new patch --- include/block/block.h | 8 include/block/block_int.h | 13 +++-- block.c

[Qemu-block] [PATCH v3 21/22] block: Fix error message style

error_setg() is not supposed to be used for multi-sentence messages; tweak the message to append a hint instead. Signed-off-by: Eric Blake --- v3: new patch --- block/raw-posix.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/raw-posix.c b/block/raw-posix.c index

[Qemu-block] [PATCH v3 20/22] block: Move request_alignment into BlockLimit

It makes more sense to have ALL block size limit constraints in the same struct. Improve the documentation while at it. Simplify a couple of conditionals, now that we have audited and documented that request_alignment is always non-zero. Signed-off-by: Eric Blake --- v3: drop dead conditionals

[Qemu-block] [PATCH v3 15/22] block: Switch transfer length bounds to byte-based

Sector-based limits are awkward to think about; in our on-going quest to move to byte-based interfaces, convert max_transfer_length and opt_transfer_length. Rename them (dropping the _length suffix) so that the compiler will help us catch the change in semantics across any rebased code, and improv

[Qemu-block] [PATCH v3 16/22] block: Wording tweaks to write zeroes limits

Improve the documentation of the write zeroes limits, to mention additional constraints that drivers should observe. Worth squashing into commit cf081fca, if that hadn't been pushed already :) Signed-off-by: Eric Blake --- v3: new patch, split off from "block: Switch discard length bounds..." -

[Qemu-block] [PATCH v3 14/22] block: Set default request_alignment during bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. Now that all drivers have been updated to supply an override of

[Qemu-block] [PATCH v3 11/22] qcow2: Set request_alignment during .bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. Signed-off-by: Eric Blake Reviewed-by: Kevin Wolf Reviewed-by

[Qemu-block] [PATCH v3 03/22] block: Fix harmless off-by-one in bdrv_aligned_preadv()

If the amount of data to read ends exactly on the total size of the bs, then we were wasting time creating a local qiov to read the data in preparation for what would normally be appending zeroes beyond the end, even though this corner case has nothing further to do. Signed-off-by: Eric Blake Rev

[Qemu-block] [PATCH v3 02/22] block: Document supported flags during bdrv_aligned_preadv()

We don't pass any flags on to drivers to handle. Tighten an assert to explain why we pass 0 to bdrv_driver_preadv(), and add some comments on things to be aware of if we want to turn on per-BDS BDRV_REQ_FUA support during reads in the future. Also, document that we may want to consider using unma

[Qemu-block] [PATCH v3 10/22] iscsi: Set request_alignment during .bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. Signed-off-by: Eric Blake Reviewed-by: Kevin Wolf Reviewed-by

[Qemu-block] [PATCH v3 06/22] iscsi: Advertise realistic limits to block layer

The function sector_limits_lun2qemu() returns a value in units of the block layer's 512-byte sector, and can be as large as 0x4000, which is much larger than the block layer's inherent limit of BDRV_REQUEST_MAX_SECTORS. The block layer already handles '0' as a synonym to the inherent limit, an

[Qemu-block] [PATCH v3 08/22] block: Give nonzero result to blk_get_max_transfer_length()

Making all callers special-case 0 as unlimited is awkward, and we DO have a hard maximum of BDRV_REQUEST_MAX_SECTORS given our current block layer API limits. In the case of scsi, this means that we now always advertise a limit to the guest, even in cases where the underlying layers previously use

[Qemu-block] [PATCH v3 13/22] block: Set request_alignment during .bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. Add a .bdrv_refresh_limits() to all four of our legacy devices

[Qemu-block] [PATCH v3 07/22] scsi: Advertise limits by blocksize, not 512

s->blocksize may be larger than 512, in which case our tweaks to max_xfer_len and opt_xfer_len must be scaled appropriately. Reported-by: Fam Zheng Signed-off-by: Eric Blake CC: qemu-sta...@nongnu.org --- v3: new patch --- hw/scsi/scsi-generic.c | 3 ++- 1 file changed, 2 insertions(+), 1 dele

[Qemu-block] [PATCH v3 05/22] nbd: Advertise realistic limits to block layer

We were basing the advertisement of maximum discard and transfer length off of UINT32_MAX, but since the rest of the block layer has signed int limits on a transaction, nothing could ever reach that maximum, and we risk overflowing an int once things are converted to byte-based rather than sector-b

[Qemu-block] [PATCH v3 01/22] block: Tighter assertions on bdrv_aligned_pwritev()

For symmetry with bdrv_aligned_preadv(), assert that the caller really has aligned things properly. This requires adding an align parameter, which is used now only in the new asserts, but will come in handy in a later patch that adds auto-fragmentation to the max transfer size, since that value nee

[Qemu-block] [PATCH v3 12/22] raw-win32: Set request_alignment during .bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. In this case, raw_probe_alignment() already did what we needed,

[Qemu-block] [PATCH v3 00/22] Byte-based block limits

BlockLimits is currently an ugly mix of byte limits vs. sector limits. Unify it. Fix some bugs I found in bdrv_aligned_preadv() while at it. Prequisite: none (built on Kevin's block branch, which is currently merged into master) Also available as a tag at: git fetch git://repo.or.cz/qemu/ericb.

[Qemu-block] [PATCH v3 09/22] blkdebug: Set request_alignment during .bdrv_refresh_limits()

We want to eventually stick request_alignment alongside other BlockLimits, but first, we must ensure it is populated at the same time as all other limits, rather than being a special case that is set only when a block is first opened. Note that when the user does not provide "align", then we were

[Qemu-block] [PATCH v3 04/22] nbd: Allow larger requests

The NBD layer was breaking up request at a limit of 2040 sectors (just under 1M) to cater to old qemu-nbd. But the server limit was raised to 32M in commit 2d8214885 to match the kernel, more than three years ago; and the upstream NBD Protocol is proposing documentation that without any explicit co

Re: [Qemu-block] [RFC PATCH 0/7] BlockBackends, nodes and guest devices

On 23/06/2016 16:36, Kevin Wolf wrote: > But of course I'm aware that there probably isn't a clear right or wrong, and > that I might be missing important details, so this needs to be discussed in > advance before I go and implement the full thing instead of just small example > patches. > > So

Re: [Qemu-block] [Qemu-devel] [PATCH 1/3] blockdev: prepare iSCSI block driver for dynamic loading

On 06/22/2016 09:22 PM, Fam Zheng wrote: > On Wed, 06/22 17:35, Colin Lord wrote: >> This commit moves the initialization of the QemuOptsList qemu_iscsi_opts >> struct out of block/iscsi.c in order to allow it to be dynamically >> loaded. Drivers that perform init operations other than registering

Re: [Qemu-block] [PATCH] iscsi: fix assertion in is_sector_request_lun_aligned

Am 23.06.2016 um 17:50 schrieb Paolo Bonzini: On 20/06/2016 11:24, Peter Lieven wrote: Commit 94d047a added an assertion the the request alignment check. This introduced 2 issues: a) A off-by-one error since a request of BDRV_REQUEST_MAX_SECTORS is actually allowed. b) The bdrv_get_bloc

Re: [Qemu-block] [PATCH] iscsi: fix assertion in is_sector_request_lun_aligned

On 20/06/2016 11:24, Peter Lieven wrote: > Commit 94d047a added an assertion the the request alignment check. > This introduced 2 issues: > a) A off-by-one error since a request of BDRV_REQUEST_MAX_SECTORS > is actually allowed. > b) The bdrv_get_block_status call in the read path to check th

[Qemu-block] [RFC PATCH 6/7] block: Accept node-name for block-stream

In order to remove the necessity to use BlockBackend names in the external API, we want to allow node-names everywhere. This is an example conversion that accepts a node-name without lifting the restriction that we're operating at a root node. Changing QMP commands so that they can work in the midd

[Qemu-block] [RFC PATCH 5/7] block: Accept device model name for blockdev-open/close-tray

This is an example conversion of a QMP command that operates on the BlockBackend level to accept both the device model name (which is supposed to become the primary interface) and the BlockBackend name. Naming suggestions for the new QMP field are welcome. The obvious one would be "device", but th

[Qemu-block] [RFC PATCH 3/7] qdev-monitor: Factor out find_device_state()

Signed-off-by: Kevin Wolf --- qdev-monitor.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/qdev-monitor.c b/qdev-monitor.c index e19617f..bc0213f 100644 --- a/qdev-monitor.c +++ b/qdev-monitor.c @@ -801,7 +801,7 @@ void qmp_device_add(QDict *qdict, QObject

[Qemu-block] [RFC PATCH 7/7] block/qdev: Allow configuring WCE with qdev properties

As cache.writeback is a BlockBackend property and as such more related to the guest device than the BlockDriverState, we already removed it from the blockdev-add interface. This patch adds the new way to set it, as a qdev property of the corresponding guest device. Signed-off-by: Kevin Wolf ---

[Qemu-block] [RFC PATCH 1/7] block/qdev: Allow node name for drive properties

If a node name instead of a BlockBackend name is specified as the driver for a guest device, an anonymous BlockBackend is created now. Signed-off-by: Kevin Wolf --- hw/core/qdev-properties-system.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/hw/core/qde

[Qemu-block] [RFC PATCH 2/7] block: Add blk_by_dev()

This finds a BlockBackend given the device model that is attached to it. Signed-off-by: Kevin Wolf --- block/block-backend.c | 19 +++ include/sysemu/block-backend.h | 1 + 2 files changed, 20 insertions(+) diff --git a/block/block-backend.c b/block/block-backend.c ind

[Qemu-block] [RFC PATCH 0/7] BlockBackends, nodes and guest devices

I am relatively confident to say that everything that should use a BlockBackend, does so by now. Almost all users create their own anonymous BlockBackend internally and use that. The user configures the BB only indirectly using the configuration methods of the user that the BB belongs to. There is

[Qemu-block] [RFC PATCH 4/7] qdev-monitor: Add blk_by_qdev_id()

This finds the BlockBackend attached to the device model identified by its qdev ID. Signed-off-by: Kevin Wolf --- include/sysemu/block-backend.h | 1 + qdev-monitor.c | 18 ++ 2 files changed, 19 insertions(+) diff --git a/include/sysemu/block-backend.h b/includ

Re: [Qemu-block] [PATCH] qcow2 resize with snapshot

hi, please help to review my code. i have checked it for serval times. it is short and very easy too read. and i will be very grateful to you for taking a very little time to read it. thanks very much! zhangzhiming zhangzhimin...@meituan.com Signed-off-by: z

Re: [Qemu-block] [PATCH v2 02/15] blockjob: Decouple the ID from the device name in the BlockJob struct

On Wed 22 Jun 2016 05:49:28 PM CEST, Kevin Wolf wrote: >> I thought adding a new 'ID' field was simpler. The device name is >> still a device name (where it makes sense). The default ID is >> guaranteed to be valid and guaranteed not to clash with user-defined >> IDs. The API is (in my opinion) mor

Re: [Qemu-block] [Qemu-devel] [PATCH] block/qdev: Fix NULL access when using BB twice

On 06/23/2016 01:30 AM, Kevin Wolf wrote: > BlockBackend has only a single pointer to its guest device, so it makes > sure that only a single guest device is attached to it. device-add > returns an error if you try to attach a second device to a BB. In order > to make the error message nicer, -devi

[Qemu-block] [PATCH 1/1] block: fix return code for partial write for Linux AIO

Partial write most likely means that there is not space rather than "something wrong happens". Thus it would be more natural to return ENOSPC rather than EINVAL. The problem actually happens with NBD server, which has reported EINVAL rather then ENOSPC on the first error using its protocol, which

[Qemu-block] [PATCH] block/qdev: Fix NULL access when using BB twice

BlockBackend has only a single pointer to its guest device, so it makes sure that only a single guest device is attached to it. device-add returns an error if you try to attach a second device to a BB. In order to make the error message nicer, -device that manually connects to a if=none block devic

Re: [Qemu-block] [Qemu-devel] [PATCH RFC 0/1] Subcommand dd for qemu-img

Reda Sallahi writes: > Hi, > > I have a first patch that adds a minimal subcommand dd for qemu-img that > is similar to dd(1) so this is a work-in-progress. > > So far it implements the bs and count options with of course the if and of > options (e.g. ./qemu-img dd if=foo.raw of=foo.qcow2 bs=128K