From: Max Reitz <mreitz@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, qemu-devel@nongnu.org
Cc: Fam Zheng <fam@euphon.net>, Paolo Bonzini <pbonzini@redhat.com>,
John Snow <jsnow@redhat.com>,
qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 5/6] block/nvme: add support for write zeros
Date: Fri, 5 Jul 2019 15:33:30 +0200 [thread overview]
Message-ID: <eb7d7240-ec4e-f0d8-2910-261ffe0a1092@redhat.com> (raw)
In-Reply-To: <20190703155944.9637-6-mlevitsk@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 4232 bytes --]
On 03.07.19 17:59, Maxim Levitsky wrote:
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
> block/nvme.c | 69 +++++++++++++++++++++++++++++++++++++++++++-
> block/trace-events | 1 +
> include/block/nvme.h | 19 +++++++++++-
> 3 files changed, 87 insertions(+), 2 deletions(-)
>
> diff --git a/block/nvme.c b/block/nvme.c
> index 152d27b07f..02e0846643 100644
> --- a/block/nvme.c
> +++ b/block/nvme.c
[...]
> @@ -469,6 +473,11 @@ static void nvme_identify(BlockDriverState *bs, int namespace, Error **errp)
> s->nsze = le64_to_cpu(idns->nsze);
> lbaf = &idns->lbaf[NVME_ID_NS_FLBAS_INDEX(idns->flbas)];
>
> + if (NVME_ID_NS_DLFEAT_WRITE_ZEROS(idns->dlfeat) &&
> + NVME_ID_NS_DLFEAT_READ_BEHAVIOR(idns->dlfeat) ==
> + NVME_ID_NS_DLFEAT_READ_BEHAVIOR_ZEROS)
> + bs->supported_write_flags |= BDRV_REQ_MAY_UNMAP;
> +
This violates the coding style, there should be curly brackets here.
> if (lbaf->ms) {
> error_setg(errp, "Namespaces with metadata are not yet supported");
> goto out;
> @@ -763,6 +772,8 @@ static int nvme_file_open(BlockDriverState *bs, QDict *options, int flags,
> int ret;
> BDRVNVMeState *s = bs->opaque;
>
> + bs->supported_write_flags = BDRV_REQ_FUA;
> +
> opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
> qemu_opts_absorb_qdict(opts, options, &error_abort);
> device = qemu_opt_get(opts, NVME_BLOCK_OPT_DEVICE);
> @@ -791,7 +802,6 @@ static int nvme_file_open(BlockDriverState *bs, QDict *options, int flags,
> goto fail;
> }
> }
> - bs->supported_write_flags = BDRV_REQ_FUA;
Any reason for this movement?
> return 0;
> fail:
> nvme_close(bs);
> @@ -1085,6 +1095,60 @@ static coroutine_fn int nvme_co_flush(BlockDriverState *bs)
> }
>
>
> +static coroutine_fn int nvme_co_pwrite_zeroes(BlockDriverState *bs,
> + int64_t offset,
> + int bytes,
> + BdrvRequestFlags flags)
> +{
> + BDRVNVMeState *s = bs->opaque;
> + NVMeQueuePair *ioq = s->queues[1];
> + NVMeRequest *req;
> +
> + if (!s->supports_write_zeros) {
> + return -ENOTSUP;
> + }
> +
> + uint32_t cdw12 = ((bytes >> s->blkshift) - 1) & 0xFFFF;
Another coding style violation: Variable declarations and other code may
not be mixed.
> +
> + NvmeCmd cmd = {
> + .opcode = NVME_CMD_WRITE_ZEROS,
> + .nsid = cpu_to_le32(s->nsid),
> + .cdw10 = cpu_to_le32((offset >> s->blkshift) & 0xFFFFFFFF),
> + .cdw11 = cpu_to_le32(((offset >> s->blkshift) >> 32) & 0xFFFFFFFF),
> + };
> +
> + NVMeCoData data = {
> + .ctx = bdrv_get_aio_context(bs),
> + .ret = -EINPROGRESS,
> + };
[...]
> diff --git a/include/block/nvme.h b/include/block/nvme.h
> index 3ec8efcc43..65eb65c740 100644
> --- a/include/block/nvme.h
> +++ b/include/block/nvme.h
> @@ -653,12 +653,29 @@ typedef struct NvmeIdNs {
> uint8_t mc;
> uint8_t dpc;
> uint8_t dps;
> - uint8_t res30[98];
> +
> + uint8_t nmic;
> + uint8_t rescap;
> + uint8_t fpi;
> + uint8_t dlfeat;
> +
> + uint8_t res30[94];
> NvmeLBAF lbaf[16];
> uint8_t res192[192];
> uint8_t vs[3712];
> } NvmeIdNs;
>
> +
> +/*Deallocate Logical Block Features*/
> +#define NVME_ID_NS_DLFEAT_GUARD_CRC(dlfeat) ((dlfeat) & 0x10)
> +#define NVME_ID_NS_DLFEAT_WRITE_ZEROS(dlfeat) ((dlfeat) & 0x04)
Isn’t it bit 3, i.e. 0x08?
Max
> +
> +#define NVME_ID_NS_DLFEAT_READ_BEHAVIOR(dlfeat) ((dlfeat) & 0x3)
> +#define NVME_ID_NS_DLFEAT_READ_BEHAVIOR_UNDEFINED 0
> +#define NVME_ID_NS_DLFEAT_READ_BEHAVIOR_ZEROS 1
> +#define NVME_ID_NS_DLFEAT_READ_BEHAVIOR_ONES 2
> +
> +
> #define NVME_ID_NS_NSFEAT_THIN(nsfeat) ((nsfeat & 0x1))
> #define NVME_ID_NS_FLBAS_EXTENDED(flbas) ((flbas >> 4) & 0x1)
> #define NVME_ID_NS_FLBAS_INDEX(flbas) ((flbas & 0xf))
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-05 13:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 15:59 [Qemu-devel] [PATCH v3 0/6] Few fixes for userspace NVME driver Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 1/6] block/nvme: don't touch the completion entries Maxim Levitsky
2019-07-05 11:03 ` Max Reitz
2019-07-07 8:43 ` Maxim Levitsky
2019-07-08 12:23 ` Max Reitz
2019-07-08 12:51 ` Maxim Levitsky
2019-07-08 13:00 ` Max Reitz
2019-07-08 13:06 ` Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 2/6] block/nvme: fix doorbell stride Maxim Levitsky
2019-07-05 11:09 ` Max Reitz
2019-07-05 11:10 ` Max Reitz
2019-07-07 8:47 ` Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 3/6] block/nvme: support larger that 512 bytes sector devices Maxim Levitsky
2019-07-05 11:58 ` Max Reitz
2019-07-07 8:51 ` Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 4/6] block/nvme: add support for image creation Maxim Levitsky
2019-07-05 12:09 ` Max Reitz
2019-07-07 9:03 ` Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 5/6] block/nvme: add support for write zeros Maxim Levitsky
2019-07-05 13:33 ` Max Reitz [this message]
2019-07-07 9:19 ` Maxim Levitsky
2019-07-03 15:59 ` [Qemu-devel] [PATCH v3 6/6] block/nvme: add support for discard Maxim Levitsky
2019-07-03 16:07 ` [Qemu-devel] [PATCH v4] " Maxim Levitsky
2019-07-05 13:50 ` Max Reitz
2019-07-07 9:40 ` Maxim Levitsky
2019-07-03 20:43 ` [Qemu-devel] [PATCH v3 0/6] Few fixes for userspace NVME driver no-reply
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=eb7d7240-ec4e-f0d8-2910-261ffe0a1092@redhat.com \
--to=mreitz@redhat.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@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).