Re: [Qemu-block] [RFC v6] RBD: Add support readv,writev for rbd

If I test , which cache mode i should choose ? writeback? or none? or default? 2017-02-21 14:50 GMT+08:00 : > From: tianqing > > Rbd can do readv and writev directly, so wo do not need to transform > iov to buf or vice versa any more. > >

[Qemu-block] [RFC v6] RBD: Add support readv,writev for rbd

From: tianqing Rbd can do readv and writev directly, so wo do not need to transform iov to buf or vice versa any more. Signed-off-by: tianqing --- block/rbd.c | 80 ++--- 1 file

Re: [Qemu-block] [RFC v6] RBD: Add support readv,writev for rbd

On Tue, Feb 21, 2017 at 11:43:36AM +0800, jaze...@gmail.com wrote: > From: tianqing > > Rbd can do readv and writev directly, so wo do not need to transform > iov to buf or vice versa any more. > > Signed-off-by: tianqing > --- > block/rbd.c

Re: [Qemu-block] [Qemu-devel] [RFC v6] RBD: Add support readv, writev for rbd

Hi, This series failed build test on s390x host. Please find the details below. Type: series Subject: [Qemu-devel] [RFC v6] RBD: Add support readv,writev for rbd Message-id: 20170221034336.10097-1-jaze...@gmail.com === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the

[Qemu-block] [RFC v6] RBD: Add support readv,writev for rbd

From: tianqing Rbd can do readv and writev directly, so wo do not need to transform iov to buf or vice versa any more. Signed-off-by: tianqing --- block/rbd.c | 79 ++--- 1 file

[Qemu-block] [PATCH v4 5/8] nbd: Implement NBD_OPT_GO on server

NBD_OPT_EXPORT_NAME is lousy: per the NBD protocol, any failure requires us to close the connection rather than report an error. Therefore, upstream NBD recently added NBD_OPT_GO as the improved version of the option that does what we want [1], along with NBD_OPT_INFO that returns the same

[Qemu-block] [PATCH v4 3/8] block: Add blk_get_opt_transfer()

The NBD protocol would like to advertise the optimal I/O size to the client; but it would be a layering violation to peek into blk_bs(blk)->bl, when we only have a BB. This copies the existing blk_get_max_transfer() in reading a value from the top BDS; where that value was picked via

[Qemu-block] [PATCH v4 8/8] nbd: Implement NBD_INFO_BLOCK_SIZE on client

The upstream NBD Protocol has defined a new extension to allow the server to advertise block sizes to the client, as well as a way for the client to inform the server whether it intends to obey block sizes. When using the block layer as the client, we will obey block sizes; but when used as

[Qemu-block] [PATCH v4 4/8] nbd: Expose and debug more NBD constants

The NBD protocol has several constants defined in various extensions that we are about to implement. Expose them to the code, along with an easy way to map various constants to strings during diagnostic messages. Doing this points out a debug message in server.c that got parameters mixed up.

[Qemu-block] [PATCH v4 6/8] nbd: Implement NBD_OPT_GO on client

NBD_OPT_EXPORT_NAME is lousy: per the NBD protocol, any failure requires the server to close the connection rather than report an error to us. Therefore, upstream NBD recently added NBD_OPT_GO as the improved version of the option that does what we want [1]: it reports sane errors on failures,

[Qemu-block] [PATCH v4 2/8] nbd: Create struct for tracking export info

The NBD Protocol is introducing some additional information about exports, such as minimum request size and alignment, as well as an advertised maximum request size. It will be easier to feed this information back to the block layer if we gather all the information into a struct, rather than

[Qemu-block] [PATCH v4 7/8] nbd: Implement NBD_INFO_BLOCK_SIZE on server

The upstream NBD Protocol has defined a new extension to allow the server to advertise block sizes to the client, as well as a way for the client to inform the server that it intends to obey block sizes. Thanks to a recent fix (commit df7b97ff), our real minimum transfer size is always 1 (the

[Qemu-block] [PATCH v4 0/8] Implement NBD_OPT_GO, block size advertisement

A bit later than I planned, but still in time for soft freeze if we like it. The NBD protocol has a proposed extension that fixes several shortcomings with NBD_OPT_EXPORT_NAME (namely, no error reporting, no way for the server to advertise block sizes to the client):

[Qemu-block] [PATCH v2] vl: disable default cdrom when using explicitely scsi-hd

In commit af6bf1328ef90fae617857c02697e0174b84d596 (May 2011), ide-hd, ide-cd and scsi-cd have been added to disable default cdrom, "or else you can't put one on secondary master without -nodefaults". Make it the same for scsi-hd, so you can put one on scsi-id 2 without using -nodefaults. scsi-hd

Re: [Qemu-block] [PATCH 23/24] util/cutils: Change qemu_strtosz*() from int64_t to uint64_t

* Markus Armbruster (arm...@redhat.com) wrote: > This will permit its use in parse_option_size(). > > Cc: Dr. David Alan Gilbert > Cc: Eduardo Habkost (maintainer:X86) > Cc: Kevin Wolf (supporter:Block layer core) > Cc: Max Reitz

Re: [Qemu-block] [Qemu-devel] [PATCH] vl: disable default cdrom when using explicitely scsi-hd

On 02/19/2017 08:00 PM, Markus Armbruster wrote: > Hervé Poussineau writes: > >> Hi, >> >> Le 09/01/2017 à 14:48, Paolo Bonzini a écrit : >>> >>> >>> On 09/01/2017 13:49, Markus Armbruster wrote: Hervé Poussineau writes: > 'ide-hd',

Re: [Qemu-block] [PATCH 22/24] util/cutils: Return qemu_strtosz*() error and value separately

* Markus Armbruster (arm...@redhat.com) wrote: > This makes qemu_strtosz(), qemu_strtosz_mebi() and > qemu_strtosz_metric() similar to qemu_strtoi64(), except negative > values are rejected. > > Cc: Dr. David Alan Gilbert > Cc: Eduardo Habkost

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-options: explain disk I/O throttling options

On 02/20/2017 10:52 AM, Stefan Hajnoczi wrote: > The disk I/O throttling options have been listed for a long time but > never explained on the QEMU man page. > > Suggested-by: Nini Gu > Cc: Alberto Garcia > Signed-off-by: Stefan Hajnoczi

Re: [Qemu-block] [PATCH 21/24] util/cutils: Let qemu_strtosz*() optionally reject trailing crap

* Markus Armbruster (arm...@redhat.com) wrote: > Change the qemu_strtosz() & friends to return -EINVAL when @endptr is > null and the conversion doesn't consume the string completely. > Matches how qemu_strtol() & friends work. > > Only test_qemu_strtosz_simple() passes a null @endptr. No

Re: [Qemu-block] [PATCH v4 13/18] qcow2: add support for LUKS encryption format

On Thu, Feb 16, 2017 at 02:42:04PM +0100, Alberto Garcia wrote: > On Fri 10 Feb 2017 06:09:05 PM CET, Daniel P. Berrange wrote: > > @@ -990,12 +1123,6 @@ static int qcow2_open(BlockDriverState *bs, QDict > > *options, int flags, > > s->refcount_max = UINT64_C(1) << (s->refcount_bits - 1); >

[Qemu-block] [PATCH] qemu-options: explain disk I/O throttling options

The disk I/O throttling options have been listed for a long time but never explained on the QEMU man page. Suggested-by: Nini Gu Cc: Alberto Garcia Signed-off-by: Stefan Hajnoczi --- qemu-options.hx | 25 + 1 file

Re: [Qemu-block] blockdev-add I/O throttling parameters

On Mon, Feb 20, 2017 at 04:45:54PM +0100, Kevin Wolf wrote: > > I can imagine two solutions that do not need these parameters in > > blockdev-add: > > > > 1. I/O throttling is implemented by a BlockDriver. Users are expected > >to create the BDS themselves. This is a little awkward since >

Re: [Qemu-block] [Qemu-devel] [PATCH 04/18] nbd/client: refactor nbd_receive_starttls

On 02/11/2017 01:30 PM, Eric Blake wrote: > On 02/03/2017 09:47 AM, Vladimir Sementsov-Ogievskiy wrote: >> Split out nbd_receive_simple_option to be reused for structured reply >> option. >> +return ""; > Can you please consider making this include the %d representation of

Re: [Qemu-block] blockdev-add I/O throttling parameters

Am 20.02.2017 um 16:30 hat Stefan Hajnoczi geschrieben: > I/O throttling parameters are missing from blockdev-add. Is this > intentional? > > I can imagine two solutions that do not need these parameters in > blockdev-add: > > 1. I/O throttling is implemented by a BlockDriver. Users are

[Qemu-block] blockdev-add I/O throttling parameters

I/O throttling parameters are missing from blockdev-add. Is this intentional? I can imagine two solutions that do not need these parameters in blockdev-add: 1. I/O throttling is implemented by a BlockDriver. Users are expected to create the BDS themselves. This is a little awkward since

[Qemu-block] [PATCH v3 4/4] qemu-img: copy *key-secret opts when opening newly created files

The qemu-img dd/convert commands will create a image file and then try to open it. Historically it has been possible to open new files without passing any options. With encrypted files though, the *key-secret options are mandatory, so we need to provide those options when opening the newly created

Re: [Qemu-block] [Qemu-devel] [PATCH v2 6/6] qemu-img: copy *key-secret opts when opening newly created files

On Mon, Feb 20, 2017 at 12:46:52PM +, Daniel P. Berrange wrote: > On Fri, Feb 03, 2017 at 11:39:35PM +0100, Max Reitz wrote: > > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > > The qemu-img dd/convert commands will create a image file and > > > then try to open it. Historically it has

[Qemu-block] [PATCH v3 1/4] qemu-img: add support for --object with 'dd' command

The qemu-img dd command added --image-opts support, but missed the corresponding --object support. This prevented passing secrets (eg auth passwords) needed by certain disk images. Reviewed-by: Eric Blake Signed-off-by: Daniel P. Berrange --- qemu-img.c

[Qemu-block] [PATCH v3 3/4] qemu-img: introduce --target-image-opts for 'convert' command

The '--image-opts' flags indicates whether the source filename includes options. The target filename has to remain in the plain filename format though, since it needs to be passed to bdrv_create(). When using --skip-create though, it would be possible to use image-opts syntax. This adds

[Qemu-block] [PATCH v3 0/4] Improve convert and dd commands

Update to v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05699.html v2: https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00728.html This series is in response to Max pointing out that you cannot use 'convert' for an encrypted target image. The 'convert' and 'dd'

[Qemu-block] [PATCH v3 2/4] qemu-img: fix --image-opts usage with dd command

The --image-opts flag can only be used to affect the parsing of the source image. The target image has to be specified in the traditional style regardless, since it needs to be passed to the bdrv_create() API which does not support the new style opts. Reviewed-by: Max Reitz

Re: [Qemu-block] [RFC PATCH V4] qemu-img: make convert async

On Fri, Feb 17, 2017 at 05:00:24PM +0100, Peter Lieven wrote: > this is something I have been thinking about for almost 2 years now. > we heavily have the following two use cases when using qemu-img convert. > > a) reading from NFS and writing to iSCSI for deploying templates > b) reading from

Re: [Qemu-block] [PATCH v15 08/25] block: introduce auto-loading bitmaps

On 02/20/2017 12:15 PM, Kevin Wolf wrote: > Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben: >> On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote: >>> 17.02.2017 17:24, Kevin Wolf wrote: Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben: > On 02/17/2017 04:34 PM, Kevin

Re: [Qemu-block] [RFC PATCH V4] qemu-img: make convert async

Am 20.02.2017 um 15:50 schrieb Stefan Hajnoczi: On Fri, Feb 17, 2017 at 05:00:24PM +0100, Peter Lieven wrote: this is something I have been thinking about for almost 2 years now. we heavily have the following two use cases when using qemu-img convert. a) reading from NFS and writing to iSCSI

Re: [Qemu-block] [RFC PATCH 27/41] block: Add bdrv_new_open_driver()

On 13.02.2017 18:22, Kevin Wolf wrote: > This function allows to create more or less normal BlockDriverStates > even for BlockDrivers that aren't globally registered (e.g. helper > filters for block jobs). > > Signed-off-by: Kevin Wolf > --- > block.c | 31

Re: [Qemu-block] [RFC PATCH 25/41] blockjob: Add permissions to block_job_add_bdrv()

On 13.02.2017 18:22, Kevin Wolf wrote: > Block jobs don't actually do I/O through the the reference they create > with block_job_add_bdrv(), but they might want to use the permisssion > system to express what the block job does to intermediate nodes. This > adds permissions to block_job_add_bdrv()

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/3] hw: Deprecate unwanted use -drive if=scsi

Paolo Bonzini writes: > On 20/02/2017 13:07, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> On 15/02/2017 14:10, Markus Armbruster wrote: Paolo Bonzini writes: > On 15/02/2017 13:18, Markus Armbruster

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/3] hw: Deprecate unwanted use -drive if=scsi

> Is that an Acked-by? > >>> > >>> Not a sufficient one because the patch touches files outside my area of > >>> maintenance, but for hw/scsi you can treat it as one. > >> > >> Okay, that covers PATCH 1/3. > >> > >> What about PATCH 3/3? It's actually your idea... > > > > Yep, hw/i386 too

Re: [Qemu-block] [RFC PATCH 20/41] hw/block: Introduce share-rw qdev property

On 20.02.2017 14:05, Kevin Wolf wrote: > Am 20.02.2017 um 13:28 hat Max Reitz geschrieben: >> On 13.02.2017 18:22, Kevin Wolf wrote: >>> By default, don't allow another writer for block devices that are >>> attached to a guest device. For the cases where this setup is intended >>> (e.g. using a

Re: [Qemu-block] [RFC PATCH 23/41] block: Include details on permission errors in message

On 13.02.2017 18:22, Kevin Wolf wrote: > Instead of just telling that there was some conflict, we can be specific > and tell which permissions were in conflict and which way the conflict > is. > > Signed-off-by: Kevin Wolf > --- > block.c | 66 >

Re: [Qemu-block] [RFC PATCH 20/41] hw/block: Introduce share-rw qdev property

Am 20.02.2017 um 13:28 hat Max Reitz geschrieben: > On 13.02.2017 18:22, Kevin Wolf wrote: > > By default, don't allow another writer for block devices that are > > attached to a guest device. For the cases where this setup is intended > > (e.g. using a cluster filesystem on the disk), the new

Re: [Qemu-block] [RFC PATCH 19/41] hw/block: Request permissions

Am 20.02.2017 um 13:25 hat Max Reitz geschrieben: > On 13.02.2017 18:22, Kevin Wolf wrote: > > This makes all device emulations with a qdev drive property request > > permissions on their BlockBackend. We don't block anything yet. > > > > Signed-off-by: Kevin Wolf > > --- > >

Re: [Qemu-block] [RFC PATCH 22/41] block: Add BdrvChildRole.get_link_name()

On 13.02.2017 18:22, Kevin Wolf wrote: > For meaningful error messages in the permission system, we want to allow > the parent of a BdrvChild to generate some kind of human-readable > identifier for the link represented by the BdrvChild. > > Signed-off-by: Kevin Wolf > --- >

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/3] hw: Deprecate unwanted use -drive if=scsi

On 20/02/2017 13:07, Markus Armbruster wrote: > Paolo Bonzini writes: > >> On 15/02/2017 14:10, Markus Armbruster wrote: >>> Paolo Bonzini writes: >>> On 15/02/2017 13:18, Markus Armbruster wrote: > Drives defined with if=scsi get connected

Re: [Qemu-block] [PATCH v2 6/6] qemu-img: copy *key-secret opts when opening newly created files

On Fri, Feb 03, 2017 at 11:39:35PM +0100, Max Reitz wrote: > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > The qemu-img dd/convert commands will create a image file and > > then try to open it. Historically it has been possible to open > > new files without passing any options. With encrypted

Re: [Qemu-block] [PATCH v2 5/6] qemu-img: introduce --target-image-opts for 'convert' command

On Fri, Feb 03, 2017 at 11:32:13PM +0100, Max Reitz wrote: > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > The '--image-opts' flags indicates whether the source filename > > includes options. The target filename has to remain in the > > plain filename format though, since it needs to be

Re: [Qemu-block] [PATCH v2 3/6] qemu-img: add support for conv=nocreat, notrunc args to dd command

On Fri, Feb 03, 2017 at 10:44:46PM +0100, Max Reitz wrote: > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > The -n arg to the convert command allows use of a pre-existing image, > > rather than creating a new image. This adds equivalent functionality > > to the dd command using the 'conv' arg.

Re: [Qemu-block] [PATCH v2 4/6] qemu-img: add support for -o arg to dd command

On Fri, Feb 03, 2017 at 11:07:13PM +0100, Max Reitz wrote: > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > The -o arg to the convert command allows specification of format/protocol > > options for the newly created image. This adds a -o arg to the dd command > > to get feature parity. > > >

Re: [Qemu-block] [PATCH v2 1/6] qemu-img: add support for --object with 'dd' command

On Fri, Feb 03, 2017 at 10:01:53PM +0100, Max Reitz wrote: > On 03.02.2017 13:02, Daniel P. Berrange wrote: > > The qemu-img dd command added --image-opts support, but missed > > the corresponding --object support. This prevented passing > > secrets (eg auth passwords) needed by certain disk

Re: [Qemu-block] [RFC PATCH 20/41] hw/block: Introduce share-rw qdev property

On 13.02.2017 18:22, Kevin Wolf wrote: > By default, don't allow another writer for block devices that are > attached to a guest device. For the cases where this setup is intended > (e.g. using a cluster filesystem on the disk), the new option can be > used to allow it. > > This change affects

Re: [Qemu-block] [RFC PATCH 19/41] hw/block: Request permissions

On 13.02.2017 18:22, Kevin Wolf wrote: > This makes all device emulations with a qdev drive property request > permissions on their BlockBackend. We don't block anything yet. > > Signed-off-by: Kevin Wolf > --- > hw/block/block.c | 19 ++- >

Re: [Qemu-block] [PATCH v15 08/25] block: introduce auto-loading bitmaps

Am 20.02.2017 um 12:21 hat Denis V. Lunev geschrieben: > On 02/20/2017 12:15 PM, Kevin Wolf wrote: > > Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben: > >> On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote: > >>> 17.02.2017 17:24, Kevin Wolf wrote: > Am 17.02.2017 um 14:48 hat

Re: [Qemu-block] [Qemu-devel] [PATCH v2 0/3] hw: Deprecate unwanted use -drive if=scsi

Paolo Bonzini writes: > On 15/02/2017 14:10, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> On 15/02/2017 13:18, Markus Armbruster wrote: Drives defined with if=scsi get connected to buses created with -device, unlike other

Re: [Qemu-block] [PATCH v15 08/25] block: introduce auto-loading bitmaps

20.02.2017 14:21, Denis V. Lunev wrote: On 02/20/2017 12:15 PM, Kevin Wolf wrote: Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben: On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote: 17.02.2017 17:24, Kevin Wolf wrote: Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben: On

Re: [Qemu-block] [RFC PATCH 18/41] block: Allow error return in BlockDevOps.change_media_cb()

On 13.02.2017 18:22, Kevin Wolf wrote: > Some devices allow a media change between read-only and read-write > media. They need to adapt the permissions in their .change_media_cb() > implementation, which can fail. So add an Error parameter to the > function. > > Signed-off-by: Kevin Wolf

Re: [Qemu-block] [RFC PATCH 16/41] block: Add error parameter to blk_insert_bs()

On 20.02.2017 12:22, Kevin Wolf wrote: > Am 20.02.2017 um 12:04 hat Max Reitz geschrieben: >> On 13.02.2017 18:22, Kevin Wolf wrote: >>> Mow that blk_insert_bs() requests the BlockBackend permissions for the >>> node it attaches to, it can fail. Instead of aborting, pass the errors >>> to the

Re: [Qemu-block] [RFC PATCH 16/41] block: Add error parameter to blk_insert_bs()

Am 20.02.2017 um 12:04 hat Max Reitz geschrieben: > On 13.02.2017 18:22, Kevin Wolf wrote: > > Mow that blk_insert_bs() requests the BlockBackend permissions for the > > node it attaches to, it can fail. Instead of aborting, pass the errors > > to the callers. > > So it does qualify as a FIXME,

Re: [Qemu-block] [RFC PATCH 17/41] block: Request real permissions in blk_new_open()

On 13.02.2017 18:22, Kevin Wolf wrote: > We can figure out the necessary permissions from the flags that the > caller passed. > > Signed-off-by: Kevin Wolf > --- > block/block-backend.c | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git

Re: [Qemu-block] [PATCH v15 08/25] block: introduce auto-loading bitmaps

Am 18.02.2017 um 11:54 hat Denis V. Lunev geschrieben: > On 02/17/2017 03:54 PM, Vladimir Sementsov-Ogievskiy wrote: > > 17.02.2017 17:24, Kevin Wolf wrote: > >> Am 17.02.2017 um 14:48 hat Denis V. Lunev geschrieben: > >>> On 02/17/2017 04:34 PM, Kevin Wolf wrote: > Am 17.02.2017 um 14:22 hat

Re: [Qemu-block] [RFC PATCH 16/41] block: Add error parameter to blk_insert_bs()

On 13.02.2017 18:22, Kevin Wolf wrote: > Mow that blk_insert_bs() requests the BlockBackend permissions for the > node it attaches to, it can fail. Instead of aborting, pass the errors > to the callers. So it does qualify as a FIXME, but just for a single patch. Good. :-) > Signed-off-by: Kevin

Re: [Qemu-block] [PATCH v15 25/25] qcow2-bitmap: improve check_constraints_on_bitmap

17.02.2017 18:48, Eric Blake wrote: On 02/17/2017 04:18 AM, Vladimir Sementsov-Ogievskiy wrote: 16.02.2017 17:21, Kevin Wolf wrote: Am 15.02.2017 um 11:10 hat Vladimir Sementsov-Ogievskiy geschrieben: Add detailed error messages. Signed-off-by: Vladimir Sementsov-Ogievskiy