[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v3 5/6] block/nvme: add support for write zeros
From: |
Maxim Levitsky |
Subject: |
Re: [Qemu-block] [PATCH v3 5/6] block/nvme: add support for write zeros |
Date: |
Sun, 07 Jul 2019 12:19:30 +0300 |
On Fri, 2019-07-05 at 15:33 +0200, Max Reitz wrote:
> On 03.07.19 17:59, Maxim Levitsky wrote:
> > Signed-off-by: Maxim Levitsky <address@hidden>
> > ---
> > 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.
100% agree + I need to see if we can update the checkpatch.pl to catch this.
>
> > 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?
This is because the nvme_identify checks if the underlying namespace
supports 'discarded data reads back as zeros', and in which case it sets the
BDRV_REQ_MAY_UNMAP in bs->supported_write_flags which later allow me to set
'deallocate' bit in the write zeros command which hints the controller
to discard the area.
This was moved to avoid overwriting the value. I could have instead just ored
the value,
but this way I think is cleaner a bit.
>
> > 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.
Another bug in checkpatch.pl :-)
>
> > +
> > + 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?
Oops, I haven't noticed that 'read behavier' field is 3 bits and not 2!
Thank you very much. I haven't caught this since my device I tested on doesn't
support this anyway (dlfeat == 0)
>
> 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))
> >
>
Thank you very very much for the review,
Best regards,
Maxim Levitsky
Re: [Qemu-block] [Qemu-devel] [PATCH v3 0/6] Few fixes for userspace NVME driver, no-reply, 2019/07/03