qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alan Adamson <alan.adamson@oracle.com>
To: qemu-devel@nongnu.org
Cc: alan.adamson@oracle.com, foss@defmacro.it, kbusch@kernel.org,
	its@irrelevant.dk, qemu-block@nongnu.org
Subject: [PATCH v3 0/1] hw/nvme: CMIC.MCTRS should be set automatically for multi-controller subsystems or by parameter
Date: Thu,  1 May 2025 11:45:04 -0700	[thread overview]
Message-ID: <20250501184505.3630283-1-alan.adamson@oracle.com> (raw)

v3: - Sync up with v10.0

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 parameter?


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


Alan Adamson (1):
  hw/nvme: CMIC.MCTRS should be set automatically for multi-controller
    subsystems or by parameter

 hw/nvme/ctrl.c   | 15 ++++++++++++++-
 hw/nvme/nvme.h   |  2 ++
 hw/nvme/subsys.c |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.43.5



             reply	other threads:[~2025-05-01 18:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-01 18:45 Alan Adamson [this message]
2025-05-01 18:45 ` [PATCH v3 1/1] hw/nvme: CMIC.MCTRS should be set automatically for multi-controller subsystems or by parameter Alan Adamson
2025-05-20 23:08   ` alan.adamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250501184505.3630283-1-alan.adamson@oracle.com \
    --to=alan.adamson@oracle.com \
    --cc=foss@defmacro.it \
    --cc=its@irrelevant.dk \
    --cc=kbusch@kernel.org \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).