On Sep 28 11:35, Dmitry Fomichev wrote: > From: Niklas Cassel > > Namespace Types introduce a new command set, "I/O Command Sets", > that allows the host to retrieve the command sets associated with > a namespace. Introduce support for the command set and enable > detection for the NVM Command Set. > > The new workflows for identify commands rely heavily on zero-filled > identify structs. E.g., certain CNS commands are defined to return > a zero-filled identify struct when an inactive namespace NSID > is supplied. > > Add a helper function in order to avoid code duplication when > reporting zero-filled identify structures. > > Signed-off-by: Niklas Cassel > Signed-off-by: Dmitry Fomichev > --- > hw/block/nvme-ns.c | 3 + > hw/block/nvme.c | 210 +++++++++++++++++++++++++++++++++++++-------- > 2 files changed, 175 insertions(+), 38 deletions(-) > > diff --git a/hw/block/nvme-ns.c b/hw/block/nvme-ns.c > index bbd7879492..31b7f986c3 100644 > --- a/hw/block/nvme-ns.c > +++ b/hw/block/nvme-ns.c > @@ -40,6 +40,9 @@ static void nvme_ns_init(NvmeNamespace *ns) > > id_ns->nsze = cpu_to_le64(nvme_ns_nlbas(ns)); > > + ns->params.csi = NVME_CSI_NVM; > + qemu_uuid_generate(&ns->params.uuid); /* TODO make UUIDs persistent */ > + It is straight-forward to put this into a 'uuid' nvme-ns parameter using DEFINE_PROP_UUID. That will default to 'auto' which will generate an UUID for each invocation, but if the user requires it to be "persistent", it can be specified explicitly. If you choose to do this, please extract to separate patch. Or I can post it on top of nvme-next if you like.