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. 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. Add a new "ready_delay" namespace device parameter, in order to emulate different ready latencies for namespaces when CC.CRIME is 1. The patch series also adds a "crwmt" controller parameter, in order to be able to expose the worst case timeout that the host should wait for all namespaces to become ready. Example qemu cmd line for the new options: # delay in s (20s) NS1_DELAY_S=20 # convert to units of 500ms NS1_DELAY=$((NS1_DELAY_S*2)) # delay in s (60s) NS2_DELAY_S=60 # convert to units of 500ms NS2_DELAY=$((NS2_DELAY_S*2)) # timeout in s (120s) CRWMT_S=120 # convert to units of 500ms CRWMT=$((CRWMT_S*2)) -device nvme,serial=deadbeef,crwmt=$CRWMT \ -drive file=$NS1_DATA,id=nvm-1,format=raw,if=none \ -device nvme-ns,drive=nvm-1,ready_delay=$NS1_DELAY \ -drive file=$NS2_DATA,id=nvm-2,format=raw,if=none \ -device nvme-ns,drive=nvm-2,ready_delay=$NS2_DELAY \ Changes since v1: -Rebased on nvme-next -Set id_indep_ns->nmic if ns->params.shared in patch 3/4. Niklas Cassel (4): hw/nvme: claim NVMe 2.0 compliance hw/nvme: store a pointer to the NvmeSubsystem in the NvmeNamespace hw/nvme: add support for ratified TP4084 hw/nvme: add new never_ready parameter to test the DNR bit hw/nvme/ctrl.c | 151 +++++++++++++++++++++++++++++++++++++++++-- hw/nvme/ns.c | 20 ++++++ hw/nvme/nvme.h | 9 +++ hw/nvme/trace-events | 1 + include/block/nvme.h | 60 ++++++++++++++++- 5 files changed, 236 insertions(+), 5 deletions(-) -- 2.36.1