The intention of the Zoned Namespace Command Set Specification was
never to make an automatic zone transition optional.
Excerpt from the nvmexpress.org zns mailing list:
"""
A question came up internally on the differences between ZNS and ZAC/ZBC
that asked about when a controller should
Since commit 916b0f0b5264 ("hw/nvme: change nvme-ns 'shared' default")
the default value of nvme-ns param 'shared' is set to true, regardless
if there is a nvme-subsys node or not.
On a system without a nvme-subsys node, a namespace will never be able
to be attached to more than one controller,
The serial prop on the controller is actually describing the nvme
subsystem serial, which has to be identical for all controllers within
the same nvme subsystem.
This is enforced since commit a859eb9f8f64 ("hw/nvme: enforce common
serial per subsystem").
Fix the documentation, so that people
TP4084 adds a new mode, CC.CRIME, that can be used to mark a namespace
as ready independently from the controller.
When CC.CRIME is 0 (default), things behave as before, all namespaces
are ready when CSTS.RDY gets set to 1.
When CC.CRIME is 1, the controller will become ready when CSTS.RDY gets
Each NvmeNamespace can be used by serveral controllers,
but a NvmeNamespace can at most belong to a single NvmeSubsystem.
Store a pointer to the NvmeSubsystem, if the namespace was realized
with a NvmeSubsystem.
This will be used by a follow up patch.
Signed-off-by: Niklas Cassel
---
Since we verify that "ready_delay" parameter has to be smaller than CRWMT,
we know that the namespace will always become ready.
Therefore the "Namespace Not Ready" status code will never have the DNR
bit set.
Add a new parameter "never_ready" that can be used to emulate a namespace
that never
Hello there,
considering that Linux v5.19 will include support for NVMe TP4084:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/nvme/host/core.c?id=354201c53e61e493017b15327294b0c8ab522d69
I thought that it might be nice to have QEMU support for the same.
CRMS.CRWMS bit shall be set to 1 on controllers compliant with versions
later than NVMe 1.4.
The first version later than NVMe 1.4 is NVMe 2.0
Let's claim compliance with NVMe 2.0 such that a follow up patch can
set the CRMS.CRWMS bit.
This is needed since CC.CRIME is only writable when both
Since we verify that "ready_delay" parameter has to be smaller than CRWMT,
we know that the namespace will always become ready.
Therefore the "Namespace Not Ready" status code will never have the DNR
bit set.
Add a new parameter "never_ready" that can be used to emulate a namespace
that never
TP4084 adds a new mode, CC.CRIME, that can be used to mark a namespace
as ready independently from the controller.
When CC.CRIME is 0 (default), things behave as before, all namespaces
are ready when CSTS.RDY gets set to 1.
When CC.CRIME is 1, the controller will become ready when CSTS.RDY gets
CRMS.CRWMS bit shall be set to 1 on controllers compliant with versions
later than NVMe 1.4.
The first version later than NVMe 1.4 is NVMe 2.0
Let's claim compliance with NVMe 2.0 such that a follow up patch can
set the CRMS.CRWMS bit.
This is needed since CC.CRIME is only writable when both
Each NvmeNamespace can be used by serveral controllers,
but a NvmeNamespace can at most belong to a single NvmeSubsystem.
Store a pointer to the NvmeSubsystem, if the namespace was realized
with a NvmeSubsystem.
This will be used by a follow up patch.
Signed-off-by: Niklas Cassel
---
Hello there,
considering that Linux v5.19-rc1 is out which includes support for
NVMe TP4084:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/nvme/host/core.c?id=354201c53e61e493017b15327294b0c8ab522d69
I thought that it might be nice to have QEMU support for the
13 matches
Mail list logo
