RE: [PATCH v5 09/14] hw/block/nvme: Support Zoned Namespace Command Set

[Dmitry Fomichev <Dmitry.Fomichev@wdc.com>]

> -----Original Message-----
> From: Niklas Cassel <Niklas.Cassel@wdc.com>
> Sent: Monday, October 5, 2020 7:41 AM
> To: Dmitry Fomichev <Dmitry.Fomichev@wdc.com>
> Cc: Alistair Francis <Alistair.Francis@wdc.com>; qemu-devel@nongnu.org;
> Damien Le Moal <Damien.LeMoal@wdc.com>; fam@euphon.net; Matias
> Bjorling <Matias.Bjorling@wdc.com>; qemu-block@nongnu.org;
> kwolf@redhat.com; mlevitsk@redhat.com; k.jensen@samsung.com;
> kbusch@kernel.org; philmd@redhat.com
> Subject: Re: [PATCH v5 09/14] hw/block/nvme: Support Zoned Namespace
> Command Set
> 
> 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.cassel@wdc.com>
> > > > Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
> > > > Signed-off-by: Ajay Joshi <ajay.joshi@wdc.com>
> > > > Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
> > > > Signed-off-by: Matias Bjorling <matias.bjorling@wdc.com>
> > > > Signed-off-by: Aravind Ramesh <aravind.ramesh@wdc.com>
> > > > Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> > > > Signed-off-by: Adam Manzanares <adam.manzanares@wdc.com>
> > > > Signed-off-by: Dmitry Fomichev <dmitry.fomichev@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.
> 

Perhaps,
NVME_SET_CSI(*list, NVME_CSI_NVM)
NVME_SET_CSI(*list, NVME_CSI_ZONED)

since this is a vector...

> (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.
> 

Ok, thanks for the clarification. I think it would be the best to add "attached"
property to namespace code instead of hardcoding it to true. The default,
of course, will be true, but will be possible to set it to false to test how everything
works with inactive namespaces. And yes, no dependence on CC.CSS.

> 
> 
> Kind regards,
> Niklas