[PATCH v2 0/1] hw/nvme: CMIC.MCTRS should be set automatically for multi-controller subsystems or by parameter

[Alan Adamson]

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