v2: - Change the parameter name from "cmic" to "cmic-mctrs".
- If there is more than 1 controller in a subsystem, set CMIC.MCTRS
for each controller whether or not the cmic-mctrs parameter is set.
While testing Linux atomic writes with qemu-nvme v10.0.0-rc1, Linux was
incorrectly displaying atomic_write_max_bytes
# cat /sys/block/nvme0n1/queue/atomic_write_max_bytes
0
# nvme id-ctrl /dev/nvme0n1 | grep awupf
awupf : 15
#
Since AWUPF was set to 15, it was expected atomic_write_max_bytes would
be set to 8192.
The commit cd59f50ab017 ("hw/nvme: always initialize a subsystem")
introduced this behavior. The commit hardcodes the subsystem cmic bit
to ON which caused the Linux NVMe driver to treat the namespace as
multi-pathed which uncovered a bug with how Atomic Write Queue Limits
were being inherited. This Linux issue is being addressed, but the
question was asked of why the subsystem CMIC.MCTRS bit was hardcoded to ON.
Most NVMe devices today don't set CMIC.MCTRS to ON. Shouldn't the setting
of this bit be a settable paramter?
Proposal:
- The default setting of the CMIC.MCTRS bit will be OFF.
- If there is more than 1 controller detected in a subsystem, the CMIC.MCTRS
bit will be set to ON for each controller in the subsystem.
- Create a subsystem specific parameter (cmic-mctrs) to specify CMIC.MCTRS
in one controller subsystems. This parameter does not affect
multi-controller subsystems.
<subsystem>,cmic-mctrs=BOOLEAN (default: off)
Example:
-device nvme-subsys,id=subsys0,cmic-mctrs=on \
-device
nvme,serial=deadbeef,id=nvme0,subsys=subsys0,atomic.dn=off,atomic.awun=31,atomic.awupf=15
\
-drive id=ns1,file=/dev/nullb0,if=none \
-device nvme-ns,drive=ns1,bus=nvme0,nsid=1,shared=false
--
2.43.5
