Re: [PATCH 0/2] virtio-scsi: Flexible max_target and max_lun params

[Karolina Stolarek <karolina.stolarek@oracle.com>]

Hi,

On 25/11/2025 12:01, Karolina Stolarek wrote:
> Currently, the maximum number of targets is set and dictated
> by virtio-scsi. On probe, the driver walks through all possible
> targets to discover which of them are available. In the process,
> it sends INQUIRY commands to request device information, also
> querying devices that don't exist. This can be observed in
> a guest with a single scsi-hd device and verbose SCSI logging
> enabled:

A gentle ping on this one.

All the best,
Karolina

> 
> scsi 0:0:0:0: scsi scan: REPORT LUN scan
> scsi 0:0:0:0: scsi scan: device exists on 0:0:0:0
> scsi 0:0:1:0: scsi scan: INQUIRY pass 1 length 36
> scsi 0:0:1:0: scsi scan: INQUIRY failed with code 0x40000
> (...)
> scsi 0:0:255:0: scsi scan: INQUIRY pass 1 length 36
> scsi 0:0:255:0: scsi scan: INQUIRY failed with code 0x40000
> 
> In the vhost-scsi backend, without the kernel patch [1], the issue
> is far more noticeable. Each command queued up for a non-existing
> target triggers vq_error(), registered by
> vhost_virtqueue_error_notifier(), resulting in a flood of
> "vhost vring error in virtqueue X" messages when booting up a VM.
> Even with the [1] patch in place, we are still sending commands
> to phantom targets with no way of limiting the scan. The first
> patch in the series addresses this issue by introducing "max_target"
> property for virtio-scsi and vhost-scsi devices. A user gets
> an option to specify how many targets are used by the guest,
> and to stop scanning before hitting VIRTIO_SCSI_MAX_TARGET.
> 
> A similar issue can be seen with Logical Units in the existing
> devices. By default, the SCSI Host Adapter instance expects
> 8 LUNs, and some drivers assume this to be the actual number
> of exposed LUNs. This results in executing SCSI commands that
> refer to non-existing Logical Units. This can be easily observed
> when using vhost-scsi backend, as such messages appear in
> the host's dmesg when booting up a guest:
> 
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000001 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000002 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000003 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000004 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000005 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000006 from
> naa.5001405277e02c68
> TARGET_CORE[vhost]: Detected NON_EXISTENT_LUN Access for 0x00000007 from
> naa.5001405277e02c68
> 
> The second patch provides a way to say how many LUNs are actually
> there by setting "max_lun" property in virtio-scsi and vhost-scsi
> devices. If neither property is defined, max_target and max_lun are
> set to the default values, making these definitions optional.
> 
> ----------------------------
> [1] -
> https://lore.kernel.org/virtualization/20250607171815.111030-1-michael.christie@oracle.com/T/#u
> 
> Karolina Stolarek (2):
>    virtio-scsi: Make max_target value configurable
>    virtio-scsi: Make max_lun value configurable
> 
>   hw/scsi/vhost-scsi.c            |  4 +++
>   hw/scsi/virtio-scsi.c           | 46 +++++++++++++++++++--------------
>   include/hw/virtio/virtio-scsi.h |  2 ++
>   3 files changed, 33 insertions(+), 19 deletions(-)
>