Re: [PATCH 2/2] vhost-scsi: reject invalid max_io_vqs module parameter

[Dongli Zhang <dongli.zhang@oracle.com>]

On 2026-07-31 5:00 PM, Michael S. Tsirkin wrote:
> On Fri, Jul 31, 2026 at 03:10:24PM -0700, Dongli Zhang wrote:
>> max_io_vqs is currently validated only when a vhost-scsi device is opened.
>> This allows sysfs to show values larger than the driver will actually use,
>> e.g. writing 2048 succeeds even though vhost_scsi_open() later clamps it to
>> VHOST_SCSI_MAX_IO_VQ. This makes the sysfs value differ from the value that
>> will actually be used.
>> 
>> hv# echo 2048 > /sys/module/vhost_scsi/parameters/max_io_vqs
>> 
>> hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs
>> 2048
>> 
>> [  315.630495] Invalid max_io_vqs of 2048. Using 1024.
>> 
>> Use a module parameter callback to reject out-of-range updates when the
>> parameter is written. This keeps the visible parameter value consistent
>> with the effective queue limit.
>> 
>> With the parameter value kept in range, remove the duplicate validation
>> from vhost_scsi_open().
>> 
>> Invalid values now fail with -EINVAL at write/load time instead of being
>> accepted and silently adjusted later when the device is opened.
>> 
>> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
> 
> why should we change userspace visible behaviour now?
> 

Everything started with PATCH 1/1.

The original purpose was to resolve the memory allocation failure addressed by
PATCH 1/1.

To validate the bugfix, I increased max_io_vqs to see what would happen.

To my surprise, I was able to increase max_io_vqs to 2048 even though
VHOST_SCSI_MAX_IO_VQ is 1024.

hv# echo 2048 > /sys/module/vhost_scsi/parameters/max_io_vqs

hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs
2048

However, a value of 2048 does not work when creating a guest VM with vhost-scsi
because vhost_scsi_open() fails.

This behavior is quite confusing.

Therefore, PATCH 2/2 was proposed to avoid confusing users. If 2048 is an
invalid value, then setting max_io_vqs to 2048 should fail explicitly.

Is this really a "userspace-visible behavior change"? Without PATCH 1/1,
increasing the default value to 256 could already fail because of memory
allocation. Perhaps this is a good opportunity to define the expected behavior
of max_io_vqs before more users start increasing its value.

This also makes the behavior of max_io_vqs consistent with inline_sg_cnt. For
module parameters, it may be better to perform sanity checks when the parameter
is configured rather than at runtime.

Thank you very much!

Dongli Zhang