[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v7 04/11] hw/block/nvme: Support allocated CNS command varian
From: |
Klaus Jensen |
Subject: |
Re: [PATCH v7 04/11] hw/block/nvme: Support allocated CNS command variants |
Date: |
Tue, 20 Oct 2020 10:21:18 +0200 |
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.
signature.asc
Description: PGP signature
- [PATCH v7 01/11] hw/block/nvme: Add Commands Supported and Effects log, (continued)
- [PATCH v7 01/11] hw/block/nvme: Add Commands Supported and Effects log, Dmitry Fomichev, 2020/10/18
- [PATCH v7 03/11] hw/block/nvme: Add support for Namespace Types, Dmitry Fomichev, 2020/10/18
- [PATCH v7 04/11] hw/block/nvme: Support allocated CNS command variants, Dmitry Fomichev, 2020/10/18
- [PATCH v7 06/11] hw/block/nvme: Introduce max active and open zone limits, Dmitry Fomichev, 2020/10/18
- [PATCH v7 05/11] hw/block/nvme: Support Zoned Namespace Command Set, Dmitry Fomichev, 2020/10/18
- [PATCH v7 08/11] hw/block/nvme: Add injection of Offline/Read-Only zones, Dmitry Fomichev, 2020/10/18