All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH v2 07/11] block: add x-blockdev-amend qmp command
Date: Fri, 08 Nov 2019 11:27:26 +0200	[thread overview]
Message-ID: <ec9879d5319d169f410e8c68bf9a880c0bc6b572.camel@redhat.com> (raw)
In-Reply-To: <931af700-bb9a-ae84-bd01-215560f66494@redhat.com>

On Fri, 2019-10-04 at 20:53 +0200, Max Reitz wrote:
> On 13.09.19 00:30, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  block/Makefile.objs       |   2 +-
> >  block/amend.c             | 116 ++++++++++++++++++++++++++++++++++++++
> >  include/block/block_int.h |  23 ++++++--
> >  qapi/block-core.json      |  26 +++++++++
> >  qapi/job.json             |   4 +-
> >  5 files changed, 163 insertions(+), 8 deletions(-)
> >  create mode 100644 block/amend.c
> 
> I think I’d move this (and everything to belongs to it) to a different
> series.
I already kind of do this, patches prior to this one fully implement
the existing amend code path, while this and patches after this
one implement the qmp x-blockdev-amend code path.

i don't mind sending this as two separate patch series, now that
first refactoring patch series is committed upsteam.


> 
> > diff --git a/block/Makefile.objs b/block/Makefile.objs
> > index 35f3bca4d9..10d0308792 100644
> > --- a/block/Makefile.objs
> > +++ b/block/Makefile.objs
> > @@ -18,7 +18,7 @@ block-obj-y += block-backend.o snapshot.o qapi.o
> >  block-obj-$(CONFIG_WIN32) += file-win32.o win32-aio.o
> >  block-obj-$(CONFIG_POSIX) += file-posix.o
> >  block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
> > -block-obj-y += null.o mirror.o commit.o io.o create.o
> > +block-obj-y += null.o mirror.o commit.o io.o create.o amend.o
> >  block-obj-y += throttle-groups.o
> >  block-obj-$(CONFIG_LINUX) += nvme.o
> >  
> > diff --git a/block/amend.c b/block/amend.c
> > new file mode 100644
> > index 0000000000..9bd28e08e7
> > --- /dev/null
> > +++ b/block/amend.c
> > @@ -0,0 +1,116 @@
> > +/*
> > + * Block layer code related to image options amend
> > + *
> > + * Copyright (c) 2018 Kevin Wolf <kwolf@redhat.com>
> > + * Copyright (c) 2019 Maxim Levitsky <mlevitsk@redhat.com>
> > + *
> > + * Heavily based on create.c
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a copy
> > + * of this software and associated documentation files (the "Software"), to deal
> > + * in the Software without restriction, including without limitation the rights
> > + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> > + * copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> > + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> > + * THE SOFTWARE.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "block/block_int.h"
> > +#include "qemu/job.h"
> > +#include "qemu/main-loop.h"
> > +#include "qapi/qapi-commands-block-core.h"
> > +#include "qapi/qapi-visit-block-core.h"
> > +#include "qapi/clone-visitor.h"
> > +#include "qapi/error.h"
> > +
> > +typedef struct BlockdevAmendJob {
> > +    Job common;
> > +    BlockdevCreateOptions *opts;
> > +    BlockDriverState *bs;
> > +    bool force;
> > +} BlockdevAmendJob;
> > +
> > +static int coroutine_fn blockdev_amend_run(Job *job, Error **errp)
> > +{
> > +    BlockdevAmendJob *s = container_of(job, BlockdevAmendJob, common);
> > +    int ret;
> > +
> > +    job_progress_set_remaining(&s->common, 1);
> > +    ret = s->bs->drv->bdrv_co_amend(s->bs, s->opts, s->force, errp);
> > +    job_progress_update(&s->common, 1);
> 
> It would be nice if the amend job could make use of the progress
> reporting that we have in place for amend.

I also thought about it, but is it worth it?

I looked through the status reporting of the qcow2 amend
code (which doesn't really allowed to be run through
qmp blockdev-amend, due to complexity of changing 
the qcow2 format on the fly).



> 
> > +
> > +    qapi_free_BlockdevCreateOptions(s->opts);
> > +
> > +    return ret;
> > +}
> > +
> > +static const JobDriver blockdev_amend_job_driver = {
> > +    .instance_size = sizeof(BlockdevAmendJob),
> > +    .job_type      = JOB_TYPE_AMEND,
> > +    .run           = blockdev_amend_run,
> > +};
> > +
> > +void qmp_x_blockdev_amend(const char *job_id,
> > +                        const char *node_name,
> > +                        BlockdevCreateOptions *options,
> > +                        bool has_force,
> > +                        bool force,
> > +                        Error **errp)
> > +{
> > +    BlockdevAmendJob *s;
> > +    const char *fmt = BlockdevDriver_str(options->driver);
> > +    BlockDriver *drv = bdrv_find_format(fmt);
> > +    BlockDriverState *bs = bdrv_find_node(node_name);
> > +
> > +    /*
> > +     * If the driver is in the schema, we know that it exists. But it may not
> > +     * be whitelisted.
> > +     */
> > +    assert(drv);
> > +    if (bdrv_uses_whitelist() && !bdrv_is_whitelisted(drv, false)) {
> > +        error_setg(errp, "Driver is not whitelisted");
> > +        return;
> > +    }
> > +
> > +    if (bs->drv != drv) {
> > +        error_setg(errp,
> > +                   "x-blockdev-amend doesn't support changing the block driver");
> > +        return;
> > +
> > +    }
> > +
> > +    /* Error out if the driver doesn't support .bdrv_co_amend */
> > +    if (!drv->bdrv_co_amend) {
> > +        error_setg(errp, "Driver does not support x-blockdev-amend");
> > +        return;
> > +    }
> > +
> > +    /*
> > +     * Create the block job
> > +     * TODO Running in the main context. Block drivers need to error out or add
> > +     * locking when they use a BDS in a different AioContext.
> 
> Why shouldn’t the job just run in the node’s context?

This is shameless copy&pasta from the blockdev-create code
(which I did note in the copyright of the file)


Best regards,
	Maxim Levitsky

> 
> Max
> 




  parent reply	other threads:[~2019-11-08  9:28 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 22:30 [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 01/11] qcrypto: add suport for amend options Maxim Levitsky
2019-09-23 13:08   ` Eric Blake
2019-09-23 13:24     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 02/11] qcrypto-luks: extend the create options for upcoming encryption key management Maxim Levitsky
2019-10-04 17:42   ` Max Reitz
2019-11-08  9:28     ` Maxim Levitsky
2019-11-08 10:48       ` Max Reitz
2019-11-08 11:48         ` Maxim Levitsky
2019-10-07  7:49   ` [Qemu-devel] " Markus Armbruster
2019-11-08  9:28     ` Maxim Levitsky
2019-10-10 13:44   ` Kevin Wolf
2019-11-08 10:04     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 03/11] qcrypto-luks: implement the " Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 04/11] block: amend: add 'force' option Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 05/11] block/crypto: implement the encryption key management Maxim Levitsky
2019-10-04 18:41   ` Max Reitz
2019-11-08  9:30     ` Maxim Levitsky
2019-11-08 10:49       ` Max Reitz
2019-11-08 11:04         ` Maxim Levitsky
2019-11-08 13:12           ` Max Reitz
2019-11-08 13:20             ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 06/11] qcow2: implement crypto amend options Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 07/11] block: add x-blockdev-amend qmp command Maxim Levitsky
2019-10-04 18:53   ` Max Reitz
2019-11-08  9:26     ` Maxim Levitsky
2019-11-08 10:36       ` Max Reitz
2019-11-08 13:37         ` Maxim Levitsky
2019-11-08  9:27     ` Maxim Levitsky [this message]
2019-10-07  7:53   ` [Qemu-devel] " Markus Armbruster
2019-11-08 15:38     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 08/11] block/crypto: implement blockdev-amend Maxim Levitsky
2019-10-07  7:58   ` Markus Armbruster
2019-11-08 15:36     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 09/11] block/qcow2: " Maxim Levitsky
2019-10-04 19:03   ` Max Reitz
2019-10-07  8:04     ` Markus Armbruster
2019-11-08 15:14       ` Maxim Levitsky
2019-11-08 15:18     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 10/11] iotests: filter few more luks specific create options Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 11/11] iotests : add tests for encryption key management Maxim Levitsky
2019-10-04 19:11   ` Max Reitz
2019-11-08  9:28     ` Maxim Levitsky
2019-09-20 21:14 ` [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface John Snow
2019-09-22  8:17   ` Maxim Levitsky
2019-10-07  8:05     ` Markus Armbruster
2019-11-06 16:43       ` Maxim Levitsky
2019-09-30 17:11   ` Maxim Levitsky
2019-10-04 19:10 ` Max Reitz
2019-11-08 15:07   ` Maxim Levitsky
2019-11-12 11:58     ` Max Reitz
2019-11-12 12:07       ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec9879d5319d169f410e8c68bf9a880c0bc6b572.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.