On Fri, Apr 17, 2026 at 05:57:24PM -0500, Mike Christie wrote:
> When exporting a NVMe drive or other high perf multiqueue enabled
> devices we may want to pass commands from the guest to the physical
> device without been throttled for artificial device wide limits. To
> allow the user to tell virtio-scsi that we don't have a LU wide
> command limit, this patch uses U32_MAX as a special cmd_per_lun value.
> 
> If U32_MAX is used for cmd_per_lun, virtio-scsi will set
> SCSI_UNLIMITED_CMD_PER_LUN for the scsi_device's queue limit. In this
> case there is no scsi_device wide queue limit and we only go by the
> the virtqueue limits (virtqueue limit is translated to scsi host
> can_queue which is translated to block layer per hardware queue limit).
> 
> There's a small chance of regression where an existing user could be
> using U32_MAX and we have been setting the cmd_per_lun to can_queue.
> However, I think in the cases the user was doing this, they will want
> the new behavior where they are only limited by can_queue because
> they have been trying to get the highest queue value possible.
> 
> Signed-off-by: Mike Christie <michael.christie@oracle.com>
> ---
>  drivers/scsi/virtio_scsi.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Hi Mike,
Please send a VIRTIO spec patch documenting the new meaning of U32_MAX
in the virtio-scsi's cmd_per_lun configuration field to
virtio-comment@lists.linux.dev. See
https://github.com/oasis-tcs/virtio-spec for details.

The Linux driver patches need to be be merged after the VIRTIO spec
change has been merged so that Linux stays spec-compliant and to avoid
collisions between in-progress VIRTIO changes.

Thanks,
Stefan