All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Hyman Huang <yong.huang@smartx.com>
Cc: qemu-devel@nongnu.org,  Kevin Wolf <kwolf@redhat.com>,
	 Hanna Reitz <hreitz@redhat.com>,  Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH] qapi: Craft the BlockdevCreateOptionsLUKS comment
Date: Wed, 21 Feb 2024 07:43:08 +0100	[thread overview]
Message-ID: <874je22u83.fsf@pond.sub.org> (raw)
In-Reply-To: <91c52e03e46ff0a96559b4e7d66ded582b2ec4e1.1708486450.git.yong.huang@smartx.com> (Hyman Huang's message of "Wed, 21 Feb 2024 11:36:58 +0800")

Hyman Huang <yong.huang@smartx.com> writes:

> Add comment in detail for commit 433957bb7f (qapi:
> Make parameter 'file' optional for
> BlockdevCreateOptionsLUKS).
>
> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> ---
>  qapi/block-core.json | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index ab5a93a966..42b0840d43 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -4973,7 +4973,25 @@
>  ##
>  # @BlockdevCreateOptionsLUKS:
>  #
> -# Driver specific image creation options for LUKS.
> +# Driver specific image creation options for LUKS. Note that
> +# @file is required if @preallocation is specified and equals
> +# PREALLOC_MODE_ON. The following three scenarios determine how
> +# creation logic behaves when @preallocation is either equal to
> +# PREALLOC_MODE_OFF or is not given:
> +#
> +#  1) When @file is given only, format the block device referenced
> +#     by @file as the LUKS specification and trunk it to the @size.

Do you mean "truncate it to @size"?

> +#     In this case, the @size should reflect amount of space made
> +#     available to the guest, so the trunk size must take account
> +#     of that which will be used by the crypto header.
> +#
> +#  2) When @header is given only, just format the block device
> +#     referenced by @header as the LUKS specification.
> +#
> +#  3) When both @file and @header are given, block device
> +#     referenced by @file should be trunked to @size, and block
> +#     device referenced by @header should be formatted as the LUKS
> +#     specification.
>  #
>  # @file: Node to create the image format on, mandatory except when
>  #        'preallocation' is not requested

Let's see whether I understand.

blockdev-create with "driver": "luks" can work in three different ways:

1. Create an image with a LUKS header

2. Create just a detached LUKS header

3. Create an image and a detached LUKS header

Correct?

@file and @header are BlockdevRef, which means they refer to existing
images with arbitrary driver.  Could be "file", "qcow2", or anything.

Correct?

To get 1., specify @file, but not @header.

To get 2., specify @header, but not @file.

To get 3., specify both.

Specifying neither is an error.

Correct?

In any case, @size is the logical size of the image (how much data it
can hold).

With 1., the actual image size is a bit larger due to the LUKS header.
The @file image is resized to that size: if it's shorter, it's grown, if
it's longer, it's truncated.

With 2., @size is merely recorded in the detached LUKS header.

With 3., @size is recorded in the detached LUKS header, and the @file
image is resized as with 1.

Correct?



  reply	other threads:[~2024-02-21  6:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-21  3:36 [PATCH] qapi: Craft the BlockdevCreateOptionsLUKS comment Hyman Huang
2024-02-21  6:43 ` Markus Armbruster [this message]
2024-02-21  7:08   ` Yong Huang
2024-02-21  8:26     ` Markus Armbruster
2024-02-21  8:49       ` Yong Huang
2024-02-28  6:43         ` Markus Armbruster
2024-02-28 10:17           ` Kevin Wolf
2024-02-28 10:23             ` Daniel P. Berrangé
2024-02-28 11:21               ` Kevin Wolf
2024-02-28 11:26                 ` Daniel P. Berrangé
2024-02-28 11:30             ` Daniel P. Berrangé
2024-02-28 11:58               ` Kevin Wolf
2024-02-29  2:04                 ` Yong Huang

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=874je22u83.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yong.huang@smartx.com \
    /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.