qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: Dmitry Fomichev <dmitry.fomichev@wdc.com>
Cc: "Fam Zheng" <fam@euphon.net>, "Kevin Wolf" <kwolf@redhat.com>,
	"Damien Le Moal" <damien.lemoal@wdc.com>,
	qemu-block@nongnu.org, "Niklas Cassel" <niklas.cassel@wdc.com>,
	"Klaus Jensen" <k.jensen@samsung.com>,
	qemu-devel@nongnu.org, "Maxim Levitsky" <mlevitsk@redhat.com>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Keith Busch" <kbusch@kernel.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Matias Bjorling" <matias.bjorling@wdc.com>
Subject: Re: [PATCH v7 04/11] hw/block/nvme: Support allocated CNS command variants
Date: Tue, 20 Oct 2020 10:21:18 +0200	[thread overview]
Message-ID: <20201020082118.GA178548@apples.localdomain> (raw)
In-Reply-To: <20201019021726.12048-5-dmitry.fomichev@wdc.com>

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

On Oct 19 11:17, Dmitry Fomichev wrote:

(snip)

> CAP.CSS (together with the I/O Command Set data structure) defines
> what command sets are supported by the controller.
> 
> CC.CSS (together with Set Profile) can be set to enable a subset of
> the available command sets.
> 
> Even if a user configures CC.CSS to e.g. Admin only, NVM namespaces
> will still be attached (and thus marked as active).
> Similarly, if a user configures CC.CSS to e.g. NVM, ZNS namespaces
> will still be attached (and thus marked as active).
> 
> However, any operation from a disabled command set will result in a
> Invalid Command Opcode.
> 

This part of the commit message seems irrelevant to the patch.

> Add a new Boolean namespace property, "attached", to provide the most
> basic namespace attachment support. The default value for this new
> property is true. Also, implement the logic in the new CNS values to
> include/exclude namespaces based on this new property. The only thing
> missing is hooking up the actual Namespace Attachment command opcode,
> which will allow a user to toggle the "attached" flag per namespace.
> 

Without Namespace Attachment support, the sole purpose of this parameter
is to allow unusable namespace IDs to be reported. I have no problems
with adding support for the additional CNS values. They will return
identical responses, but I think that is good enough for now.

When it is not really needed, we should be wary of adding a parameter
that is really hard to get rid of again.

> The reason for not hooking up this command completely is because the
> NVMe specification requires the namespace management command to be
> supported if the namespace attachment command is supported.
> 

There are many ways to support Namespace Management, and there are a lot
of quirks with each of them. Do we use a big blockdev and carve out
namespaces? Then, what are the semantics of an image resize operation?

Do we dynamically create blockdev devices - thats sounds pretty nice,
but might have other quirks and the attachment is not really persistent.

I think at least the "attached" parameter should be x-prefixed, but
better, leave it out for now until we know how we want Namespace
Attachment and Management to be implemented.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-10-20  8:26 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19  2:17 [PATCH v7 00/11] hw/block/nvme: Support Namespace Types and Zoned Namespace Command Set Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 01/11] hw/block/nvme: Add Commands Supported and Effects log Dmitry Fomichev
2020-10-19 19:22   ` Keith Busch
2020-10-19 20:16   ` Klaus Jensen
2020-10-20 23:04     ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 02/11] hw/block/nvme: Generate namespace UUIDs Dmitry Fomichev
2020-10-19 19:24   ` Keith Busch
2020-10-19 19:30   ` Klaus Jensen
2020-10-19  2:17 ` [PATCH v7 03/11] hw/block/nvme: Add support for Namespace Types Dmitry Fomichev
2020-10-19 19:51   ` Keith Busch
2020-10-19 20:53   ` Klaus Jensen
2020-10-21  1:50     ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 04/11] hw/block/nvme: Support allocated CNS command variants Dmitry Fomichev
2020-10-19 20:07   ` Keith Busch
2020-10-20  8:21   ` Klaus Jensen [this message]
2020-10-20 23:09     ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 05/11] hw/block/nvme: Support Zoned Namespace Command Set Dmitry Fomichev
2020-10-19  9:50   ` Klaus Jensen
2020-10-19 15:55     ` Klaus Jensen
2020-10-19 12:33   ` Klaus Jensen
2020-10-20 11:08   ` Klaus Jensen
2020-10-21 10:26   ` Klaus Jensen
2020-10-21 23:19     ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 06/11] hw/block/nvme: Introduce max active and open zone limits Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 07/11] hw/block/nvme: Support Zone Descriptor Extensions Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 08/11] hw/block/nvme: Add injection of Offline/Read-Only zones Dmitry Fomichev
2020-10-19 11:42   ` Klaus Jensen
2020-10-20 23:01     ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 09/11] hw/block/nvme: Document zoned parameters in usage text Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 10/11] hw/block/nvme: Separate read and write handlers Dmitry Fomichev
2020-10-20  8:28   ` Klaus Jensen
2020-10-20 12:36     ` Keith Busch
2020-10-20 23:05       ` Dmitry Fomichev
2020-10-19  2:17 ` [PATCH v7 11/11] hw/block/nvme: Merge nvme_write_zeroes() with nvme_write() Dmitry Fomichev
2020-10-20  8:29   ` Klaus Jensen
2020-10-19  7:32 ` [PATCH v7 00/11] hw/block/nvme: Support Namespace Types and Zoned Namespace Command Set Niklas Cassel

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=20201020082118.GA178548@apples.localdomain \
    --to=its@irrelevant.dk \
    --cc=alistair.francis@wdc.com \
    --cc=damien.lemoal@wdc.com \
    --cc=dmitry.fomichev@wdc.com \
    --cc=fam@euphon.net \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=matias.bjorling@wdc.com \
    --cc=mlevitsk@redhat.com \
    --cc=niklas.cassel@wdc.com \
    --cc=philmd@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).