On Sun, Oct 04, 2020 at 11:57:07PM +0000, Dmitry Fomichev wrote:
> On Wed, 2020-09-30 at 14:50 +0000, Niklas Cassel wrote:
> > On Mon, Sep 28, 2020 at 11:35:23AM +0900, Dmitry Fomichev wrote:
> > > The emulation code has been changed to advertise NVM Command Set when
> > > "zoned" device property is not set (default) and Zoned Namespace
> > > Command Set otherwise.
> > >
> > > Handlers for three new NVMe commands introduced in Zoned Namespace
> > > Command Set specification are added, namely for Zone Management
> > > Receive, Zone Management Send and Zone Append.
> > >
> > > Device initialization code has been extended to create a proper
> > > configuration for zoned operation using device properties.
> > >
> > > Read/Write command handler is modified to only allow writes at the
> > > write pointer if the namespace is zoned. For Zone Append command,
> > > writes implicitly happen at the write pointer and the starting write
> > > pointer value is returned as the result of the command. Write Zeroes
> > > handler is modified to add zoned checks that are identical to those
> > > done as a part of Write flow.
> > >
> > > The code to support for Zone Descriptor Extensions is not included in
> > > this commit and ZDES 0 is always reported. A later commit in this
> > > series will add ZDE support.
> > >
> > > This commit doesn't yet include checks for active and open zone
> > > limits. It is assumed that there are no limits on either active or
> > > open zones.
> > >
> > > Signed-off-by: Niklas Cassel <niklas.cas...@wdc.com>
> > > Signed-off-by: Hans Holmberg <hans.holmb...@wdc.com>
> > > Signed-off-by: Ajay Joshi <ajay.jo...@wdc.com>
> > > Signed-off-by: Chaitanya Kulkarni <chaitanya.kulka...@wdc.com>
> > > Signed-off-by: Matias Bjorling <matias.bjorl...@wdc.com>
> > > Signed-off-by: Aravind Ramesh <aravind.ram...@wdc.com>
> > > Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawas...@wdc.com>
> > > Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>
> > > Signed-off-by: Dmitry Fomichev <dmitry.fomic...@wdc.com>
> > > ---
> > > block/nvme.c | 2 +-
> > > hw/block/nvme-ns.c | 185 ++++++++-
> > > hw/block/nvme-ns.h | 6 +-
> > > hw/block/nvme.c | 872 +++++++++++++++++++++++++++++++++++++++++--
> > > include/block/nvme.h | 6 +-
> > > 5 files changed, 1033 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/block/nvme.c b/block/nvme.c
> > > index 05485fdd11..7a513c9a17 100644
> > > --- a/block/nvme.c
> > > +++ b/block/nvme.c
(snip)
> >
> > Please read my comment on nvme_identify_nslist_csi() before reading
> > this comment.
> >
> > At least for this function, the specification is clear:
> >
> > "If the host requests a data structure for an I/O Command Set that the
> > controller does not support, the controller shall abort the command with
> > a status of Invalid Field in Command."
> >
> > If the controller supports the I/O command set == if the Command Set bit
> > is set in the data struct returned by the nvme_identify_cmd_set(),
> > so here we should do something like:
> >
> > } else if (->csi == NVME_CSI_ZONED && ctrl_has_zns_namespaces()) {
> > ...
> > }
> >
>
> With this commit, the controller supports ZNS command set regardless of
> the number of attached ZNS namespaces. It could be zero, but the controller
> still supports it. I think it would be better not to change the behavior
> of this command to depend on whether there are any ZNS namespaces added
> or not.
Ok, always having ZNS Command Set support, regardless if a user defines
a zoned namespace on the QEMU command line or not, does simplify things.
But then in nvme_identify_cmd_set(), you need to call
NVME_SET_CSI(*list, NVME_CSI_ZONED) unconditionally.
(Right now you loop though all namespaces, and only set the support bit
if you find a zoned namespace.)
> > Like I wrote in my review comment in the patch that added support for the
> > new
> > allocated CNS values, I prefer if we remove this for-loop completely, and
> > simply set attached = true in nvme_ns_setup()/nvme_ns_init() instead.
> >
> > (I was considering if we should set attach = true in nvme_zoned_init_ns(),
> > but because nvme_ns_setup()/nvme_ns_init() is called for all namespaces,
> > including ZNS namespaces, I don't think that any additional code in
> > nvme_zoned_init_ns() is warranted.)
>
> I think CC.CSS value is not available during namespace setup and if we
> assign active flag in nvme_zoned_ns_setup(), zoned namespaces may end up
> being active even if NVM Only command set is selected. So keeping this loop
> seems like a good idea.
It is true that CC.CSS is not yet available during namespace setup,
but since the controller itself will never detach namespaces based on
CC.CSS, why are we dependant on CC.CSS being available?
Sure, once someone implements namespace management, they will need
to read if a certain namespace is attached or detached from some
persistent state, perhaps in the zone meta-data file, and set
attached boolean in nvme_ns_init() accordingly, but I still don't see
any dependance on CC.CSS even when namespace management is implemented.
Kind regards,
Niklas
