From: Max Reitz <mreitz@redhat.com>
To: Maxim Levitsky <mlevitsk@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 09/11] block/qcow2: implement blockdev-amend
Date: Fri, 4 Oct 2019 21:03:16 +0200 [thread overview]
Message-ID: <c26f4f4a-2f2e-84d9-a516-36c7150b6332@redhat.com> (raw)
In-Reply-To: <20190912223028.18496-10-mlevitsk@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 6200 bytes --]
On 13.09.19 00:30, Maxim Levitsky wrote:
> Currently only for changing crypto parameters
Yep, that elegantly avoids most of the problems we’d have otherwise. :-)
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
> block/qcow2.c | 71 ++++++++++++++++++++++++++++++++++++++++++++
> qapi/block-core.json | 6 ++--
> 2 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 26f83aeb44..c8847ec6e2 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -3079,6 +3079,18 @@ qcow2_co_create(BlockdevCreateOptions *create_options, Error **errp)
> assert(create_options->driver == BLOCKDEV_DRIVER_QCOW2);
> qcow2_opts = &create_options->u.qcow2;
>
> + if (!qcow2_opts->has_size) {
> + error_setg(errp, "Size is manadatory for image creation");
> + return -EINVAL;
> +
> + }
> +
> + if (!qcow2_opts->has_file) {
> + error_setg(errp, "'file' is manadatory for image creation");
> + return -EINVAL;
> +
> + }
> +
> bs = bdrv_open_blockdev_ref(qcow2_opts->file, errp);
> if (bs == NULL) {
> return -EIO;
> @@ -5111,6 +5123,64 @@ static int qcow2_amend_options(BlockDriverState *bs, QemuOpts *opts,
> return 0;
> }
>
> +
> +static int coroutine_fn qcow2_co_amend(BlockDriverState *bs,
> + BlockdevCreateOptions *opts,
> + bool force,
> + Error **errp)
> +{
> + BlockdevCreateOptionsQcow2 *qopts = &opts->u.qcow2;
> + BDRVQcow2State *s = bs->opaque;
> + int ret;
> +
> + /*
> + * This is ugly as hell, in later versions of this patch
> + * something has to be done about this
Well, at least the language of the comment needs adjustment. :-)
> + */
> + if (qopts->has_file || qopts->has_size || qopts->has_data_file ||
> + qopts->has_data_file_raw || qopts->has_version ||
> + qopts->has_backing_file || qopts->has_backing_fmt ||
> + qopts->has_cluster_size || qopts->has_preallocation ||
> + qopts->has_lazy_refcounts || qopts->has_refcount_bits) {
> +
> + error_setg(errp,
> + "Only LUKS encryption options can be amended for qcow2 with blockdev-amend");
> + return -EOPNOTSUPP;
> +
> + }
> +
> + if (qopts->has_encrypt) {
> + if (!s->crypto) {
> + error_setg(errp, "QCOW2 image is not encrypted, can't amend");
> + return -EOPNOTSUPP;
> + }
> +
> + if (qopts->encrypt->format != Q_CRYPTO_BLOCK_FORMAT_LUKS) {
> + error_setg(errp,
> + "Amend can't be used to change the qcow2 encryption format");
> + return -EOPNOTSUPP;
> + }
> +
> + if (s->crypt_method_header != QCOW_CRYPT_LUKS) {
> + error_setg(errp,
> + "Only LUKS encryption options can be amended for qcow2 with blockdev-amend");
> + return -EOPNOTSUPP;
> + }
> +
> + ret = qcrypto_block_amend_options(s->crypto,
> + qcow2_crypto_hdr_read_func,
> + qcow2_crypto_hdr_write_func,
> + bs,
> + qopts->encrypt,
> + force,
> + errp);
> + if (ret) {
> + return ret;
> + }
> + }
> + return 0;
I suppose we need to do the same permission stuff as for LUKS, though;
i.e., unshare CONSISTENT_READ while this operation is ongoing.
> +}
> +
> /*
> * If offset or size are negative, respectively, they will not be included in
> * the BLOCK_IMAGE_CORRUPTED event emitted.
> @@ -5303,6 +5373,7 @@ BlockDriver bdrv_qcow2 = {
> .mutable_opts = mutable_opts,
> .bdrv_co_check = qcow2_co_check,
> .bdrv_amend_options = qcow2_amend_options,
> + .bdrv_co_amend = qcow2_co_amend,
>
> .bdrv_detach_aio_context = qcow2_detach_aio_context,
> .bdrv_attach_aio_context = qcow2_attach_aio_context,
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 4a6db98938..0eb4e45168 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -4294,6 +4294,7 @@
> # Driver specific image creation options for qcow2.
> #
> # @file Node to create the image format on
> +# Mandatory for create
> # @data-file Node to use as an external data file in which all guest
> # data is stored so that only metadata remains in the qcow2
> # file (since: 4.0)
> @@ -4301,6 +4302,7 @@
> # standalone (read-only) raw image without looking at qcow2
> # metadata (default: false; since: 4.0)
> # @size Size of the virtual disk in bytes
> +# Mandatory for create
> # @version Compatibility level (default: v3)
> # @backing-file File name of the backing file if a backing file
> # should be used
> @@ -4315,10 +4317,10 @@
> # Since: 2.12
> ##
> { 'struct': 'BlockdevCreateOptionsQcow2',
> - 'data': { 'file': 'BlockdevRef',
> + 'data': { '*file': 'BlockdevRef',
> '*data-file': 'BlockdevRef',
> '*data-file-raw': 'bool',
> - 'size': 'size',
> + '*size': 'size',
> '*version': 'BlockdevQcow2Version',
> '*backing-file': 'str',
> '*backing-fmt': 'BlockdevDriver',
>
Making these fields optional makes me wonder whether it actually make
sense to have both create and amend share a single QAPI structure.
Wouldn’t it better to have a separate amend structure that then actually
reflects what we support? (This would also solve the problem of how to
express in the code what is and what isn’t supported through
blockdev-amend.)
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-04 19:08 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
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 [this message]
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=c26f4f4a-2f2e-84d9-a516-36c7150b6332@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).