linux-toradex.git/drivers/vhost, branch master Linux kernel for Apalis and Colibri modules Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost 2026-10-24T00:19:27+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-10-24T00:19:27+00:00 9f2516f45b7cfca237f4d8e1c91c1f307e295dc5 Pull vhost,virtio updates from Michael Tsirkin: "This adds CPR support for vhost. Plus some fixes, notably for a host of races we had when callback fire around device reset" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: tools/virtio: add missing device-id/virtio.h wrapper header vhost/vsock: add VHOST_RESET_OWNER ioctl vhost: synchronize with RCU readers when freeing workers vhost/vsock: re-scan TX virtqueue on device start vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause vhost/vsock: split out vhost_vsock_drop_backends helper virtio_pci: drop callback sync on reset virtio_pci_modern: move avq cleanup from reset to del_vqs virtio: synchronize callbacks after device reset virtio_vdpa: implement synchronize_cbs() platform/mellanox: mlxbf-tmfifo: implement synchronize_cbs() um: virtio_uml: implement synchronize_cbs() remoteproc: implement synchronize_cbs() for virtio devices virtio_ccw: always take irq_lock in the classic interrupt handler virtio_ccw: fix synchronize_cbs() after interrupt fallback 
Pull vhost,virtio updates from Michael Tsirkin:
 "This adds CPR support for vhost.

  Plus some fixes, notably for a host of races we had when callback fire
  around device reset"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  tools/virtio: add missing device-id/virtio.h wrapper header
  vhost/vsock: add VHOST_RESET_OWNER ioctl
  vhost: synchronize with RCU readers when freeing workers
  vhost/vsock: re-scan TX virtqueue on device start
  vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause
  vhost/vsock: split out vhost_vsock_drop_backends helper
  virtio_pci: drop callback sync on reset
  virtio_pci_modern: move avq cleanup from reset to del_vqs
  virtio: synchronize callbacks after device reset
  virtio_vdpa: implement synchronize_cbs()
  platform/mellanox: mlxbf-tmfifo: implement synchronize_cbs()
  um: virtio_uml: implement synchronize_cbs()
  remoteproc: implement synchronize_cbs() for virtio devices
  virtio_ccw: always take irq_lock in the classic interrupt handler
  virtio_ccw: fix synchronize_cbs() after interrupt fallback
vhost: vringh: use get_user()/put_user() for IOTLB 16-bit accesses 2026-10-20T18:06:57+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-10-20T05:24:08+00:00 95a214f31a3b1ef40034f1e1cb3b9d758a374f01 getu16_iotlb() and putu16_iotlb() use __get_user() and __put_user() when the IOTLB maps to user virtual addresses. Nothing nearby checks the translated address: that relies on the mapping having been validated against the user's VMAs when it was set up. Use get_user() and put_user(), which do the same single, untorn access and also check the address. The only atomic-context use, the vdpa simulators' notification check, now disables page faults around it, so the might_fault() in the checked accessors stays quiet there. This is part of getting rid of __get_user() and __put_user() entirely. Tested-and-acked-by: Michael S. Tsirkin <mst@redhat.com> Fixes: 42823a871fd4 ("vringh: support VA with iotlb") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
getu16_iotlb() and putu16_iotlb() use __get_user() and __put_user() when
the IOTLB maps to user virtual addresses.  Nothing nearby checks the
translated address: that relies on the mapping having been validated
against the user's VMAs when it was set up.

Use get_user() and put_user(), which do the same single, untorn access
and also check the address.  The only atomic-context use, the vdpa
simulators' notification check, now disables page faults around it, so
the might_fault() in the checked accessors stays quiet there.

This is part of getting rid of __get_user() and __put_user() entirely.

Tested-and-acked-by: Michael S. Tsirkin <mst@redhat.com>
Fixes: 42823a871fd4 ("vringh: support VA with iotlb")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
vhost/vsock: add VHOST_RESET_OWNER ioctl 2026-09-17T15:39:30+00:00 Pavel Tikhomirov ptikhomirov@virtuozzo.com 2026-07-24T11:45:42+00:00 8f2c2fb94a01320e5136c6e89a47fb12355ad27c This ioctl is needed for QEMU's CPR (checkpoint-restore) migration of the guest with vhost-vsock device. For this to work, we need to reset the device ownership on the source side by calling RESET_OWNER, and then claim it on the dest side by calling SET_OWNER. We expect not to lose any AF_VSOCK connection while this happens. To that end, unlike the release path, RESET_OWNER keeps the guest CID hashed: established connections survive, and host sends issued while the device is between owners simply stay on send_pkt_queue until the next device start drains them. Since the device stays reachable through the CID hash, the lockless send/cancel paths can race with the worker teardown in vhost_workers_free(). The previous commit ("vhost: synchronize with RCU readers when freeing workers") makes that safe. Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260724114542.734623-6-andrey.drobyshev@virtuozzo.com> 
This ioctl is needed for QEMU's CPR (checkpoint-restore) migration of
the guest with vhost-vsock device.  For this to work, we need to reset
the device ownership on the source side by calling RESET_OWNER, and then
claim it on the dest side by calling SET_OWNER.  We expect not to lose any
AF_VSOCK connection while this happens.

To that end, unlike the release path, RESET_OWNER keeps the guest CID
hashed: established connections survive, and host sends issued while
the device is between owners simply stay on send_pkt_queue until the
next device start drains them.

Since the device stays reachable through the CID hash, the lockless
send/cancel paths can race with the worker teardown in
vhost_workers_free().  The previous commit ("vhost: synchronize with
RCU readers when freeing workers") makes that safe.

Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724114542.734623-6-andrey.drobyshev@virtuozzo.com>
vhost: synchronize with RCU readers when freeing workers 2026-09-17T15:39:30+00:00 Andrey Drobyshev andrey.drobyshev@virtuozzo.com 2026-07-24T11:45:41+00:00 5efd97e6f0c745d5cb34e4e3b709200e23d4d7b7 vhost_vq_work_queue() only holds the RCU read lock while it dereferences vq->worker and queues work on it. vhost_workers_free() however clears the vq->worker pointers and immediately frees the workers, without waiting for a grace period. A caller that fetched the worker right before the pointer was cleared can therefore still be queueing work on it while it is freed. And even when the queueing itself wins the race, the work is never run, so its VHOST_WORK_QUEUED bit stays set and all future attempts to queue it are silently skipped. None of the current callers can actually hit this: net and scsi stop their virtqueues before the workers are freed, and vsock unhashes the device and does synchronize_rcu() of its own in vhost_vsock_dev_release() before the workers go away. But the upcoming VHOST_RESET_OWNER support in vhost-vsock keeps the device hashed while its workers are freed, so the lockless send/cancel paths become able to race with the teardown. Fix this by threading a bool 'sync' param through the chain: vhost_dev_reset_owner() vhost_dev_cleanup() vhost_workers_free() When set, after clearing the vq->worker pointers, wait for a grace period and flush the workers so any work the last RCU readers queued runs (clearing VHOST_WORK_QUEUED) before the workers are freed. Only the vsock RESET_OWNER path (added in the next patch) passes sync=true; every other teardown has already quiesced and passes false, so they do not need to wait the grace period. Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260724114542.734623-5-andrey.drobyshev@virtuozzo.com> 
vhost_vq_work_queue() only holds the RCU read lock while it dereferences
vq->worker and queues work on it.  vhost_workers_free() however clears
the vq->worker pointers and immediately frees the workers, without
waiting for a grace period.  A caller that fetched the worker right
before the pointer was cleared can therefore still be queueing work on
it while it is freed.  And even when the queueing itself wins the race,
the work is never run, so its VHOST_WORK_QUEUED bit stays set and all
future attempts to queue it are silently skipped.

None of the current callers can actually hit this: net and scsi stop
their virtqueues before the workers are freed, and vsock unhashes the
device and does synchronize_rcu() of its own in vhost_vsock_dev_release()
before the workers go away.  But the upcoming VHOST_RESET_OWNER support
in vhost-vsock keeps the device hashed while its workers are freed, so
the lockless send/cancel paths become able to race with the teardown.

Fix this by threading a bool 'sync' param through the chain:

  vhost_dev_reset_owner()
    vhost_dev_cleanup()
      vhost_workers_free()

When set, after clearing the vq->worker pointers, wait for a grace
period and flush the workers so any work the last RCU readers queued
runs (clearing VHOST_WORK_QUEUED) before the workers are freed.  Only
the vsock RESET_OWNER path (added in the next patch) passes sync=true;
every other teardown has already quiesced and passes false, so they do
not need to wait the grace period.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724114542.734623-5-andrey.drobyshev@virtuozzo.com>
vhost/vsock: re-scan TX virtqueue on device start 2026-09-17T15:39:29+00:00 Andrey Drobyshev andrey.drobyshev@virtuozzo.com 2026-07-24T11:45:40+00:00 bb52825eddec2801ae9ace88f53dfee01d22b9bd During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest keeps running while the host drops and later re-attaches vhost backends. If the guest adds a buffer to the TX virtqueue (guest->host) and kicks while the backend is temporarily NULL (between vhost_vsock_drop_backends() and the next vhost_vsock_start()), then the kick is delivered to the vhost worker, handle_tx_kick() sees a NULL backend and returns, and the kick signal is consumed. The buffer is then left in the ring. Then upon device start vhost_vsock_start() only re-kicks the RX send worker, never the TX VQ, so the buffer is processed only if the guest happens to kick again. But if the guest itself is now waiting for data from the host, it will never kick TX VQ again, and we end up in a deadlock. The issue itself is pre-existing, but it only manifests during a device pause caused by VHOST_RESET_OWNER. Namely, the deadlock is reproduced during active host->guest socat data transfer under multiple consecutive CPR live-update's. To fix this, in vhost_vsock_start(), after kicking the RX send worker, also queue the TX vq poll so any buffers the guest enqueued while we were paused get scanned. The VHOST_RESET_OWNER ioctl itself is implemented in the following patch, thus this patch is a preparation to support VHOST_RESET_OWNER. Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260724114542.734623-4-andrey.drobyshev@virtuozzo.com> 
During QEMU CPR live-update (and VHOST_RESET_OWNER in general) the guest
keeps running while the host drops and later re-attaches vhost backends.
If the guest adds a buffer to the TX virtqueue (guest->host) and kicks
while the backend is temporarily NULL (between vhost_vsock_drop_backends()
and the next vhost_vsock_start()), then the kick is delivered to the
vhost worker, handle_tx_kick() sees a NULL backend and returns, and the
kick signal is consumed.  The buffer is then left in the ring.

Then upon device start vhost_vsock_start() only re-kicks the RX send
worker, never the TX VQ, so the buffer is processed only if the guest
happens to kick again.  But if the guest itself is now waiting for data
from the host, it will never kick TX VQ again, and we end up in a
deadlock.

The issue itself is pre-existing, but it only manifests during a device
pause caused by VHOST_RESET_OWNER.  Namely, the deadlock is reproduced
during active host->guest socat data transfer under multiple consecutive
CPR live-update's.

To fix this, in vhost_vsock_start(), after kicking the RX send worker, also
queue the TX vq poll so any buffers the guest enqueued while we were paused
get scanned.

The VHOST_RESET_OWNER ioctl itself is implemented in the following
patch, thus this patch is a preparation to support VHOST_RESET_OWNER.

Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724114542.734623-4-andrey.drobyshev@virtuozzo.com>
vhost/vsock: suppress EHOSTUNREACH fast-fail during CPR pause 2026-09-17T15:39:29+00:00 Andrey Drobyshev andrey.drobyshev@virtuozzo.com 2026-07-24T11:45:39+00:00 a29f2afa2d73c28f2290c7b3232e467d703035b5 Earlier commit bb26ed5f3a8b ("vhost/vsock: Refuse the connection immediately when guest isn't ready") added a fast-fail in vhost_transport_send_pkt(). It rejects every host send with -EHOSTUNREACH until the destination calls SET_RUNNING(1). The fast-fail condition checks whether device's backends are dropped, and if they're, the guest is considered to be not ready. However, there might be other reasons for backends to be nulled. In particular, when QEMU is performing CPR (checkpoint-restore) migration, device ownership is being RESET and SET again, which leads to backends drop and reattach. If we end up connecting during this window, an AF_VSOCK client gets -EHOSTUNREACH, which is wrong. Add an 'ever_started' flag which is set once in vhost_vsock_start() and is never cleared. The behaviour changes to: * When device was never started -> flag is unset -> no listener can exist yet -> fast-fail; * Once the device starts -> flag is set -> we don't fast-fail -> we queue and preserve during any later stop / CPR pause. The VHOST_RESET_OWNER ioctl is implemented in a following patch, and without RESET_OWNER the problem we fix here isn't manifesting - thus this patch is a preparation to support RESET_OWNER. Important caveat: after the first start, a connect during any stopped window is queued instead of fast-failed. That was the behaviour before the patch bb26ed5f3a8b, and we're restoring it now. However we still keep the behaviour originally intended by that commit (i.e. fast-fail if there's no real listener yet) while fixing the CPR path. Suggested-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Denis V. Lunev <den@openvz.org> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260724114542.734623-3-andrey.drobyshev@virtuozzo.com> 
Earlier commit bb26ed5f3a8b ("vhost/vsock: Refuse the connection
immediately when guest isn't ready") added a fast-fail in
vhost_transport_send_pkt().  It rejects every host send with -EHOSTUNREACH
until the destination calls SET_RUNNING(1).  The fast-fail condition checks
whether device's backends are dropped, and if they're, the guest is
considered to be not ready.

However, there might be other reasons for backends to be nulled.  In
particular, when QEMU is performing CPR (checkpoint-restore) migration,
device ownership is being RESET and SET again, which leads to backends
drop and reattach.  If we end up connecting during this window, an
AF_VSOCK client gets -EHOSTUNREACH, which is wrong.

Add an 'ever_started' flag which is set once in vhost_vsock_start() and is
never cleared.  The behaviour changes to:

  * When device was never started -> flag is unset -> no listener can
    exist yet -> fast-fail;
  * Once the device starts -> flag is set -> we don't fast-fail ->
    we queue and preserve during any later stop / CPR pause.

The VHOST_RESET_OWNER ioctl is implemented in a following patch, and
without RESET_OWNER the problem we fix here isn't manifesting - thus
this patch is a preparation to support RESET_OWNER.

Important caveat: after the first start, a connect during any stopped
window is queued instead of fast-failed.  That was the behaviour before
the patch bb26ed5f3a8b, and we're restoring it now.  However we still
keep the behaviour originally intended by that commit (i.e. fast-fail if
there's no real listener yet) while fixing the CPR path.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Denis V. Lunev <den@openvz.org>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724114542.734623-3-andrey.drobyshev@virtuozzo.com>
vhost/vsock: split out vhost_vsock_drop_backends helper 2026-09-17T15:39:29+00:00 Pavel Tikhomirov ptikhomirov@virtuozzo.com 2026-07-24T11:45:38+00:00 01b8354fa2bc33f411837ac2f6dccfc8dceda96c Split the actual backend dropping part from vhost_vsock_stop. We're going to need it for the VHOST_RESET_OWNER implementation in the following patch, when vsock->dev.mutex is already taken and owner is checked. Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260724114542.734623-2-andrey.drobyshev@virtuozzo.com> 
Split the actual backend dropping part from vhost_vsock_stop.  We're
going to need it for the VHOST_RESET_OWNER implementation in the
following patch, when vsock->dev.mutex is already taken and owner is
checked.

Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260724114542.734623-2-andrey.drobyshev@virtuozzo.com>
vhost: invalidate vring access on IOTLB transitions 2026-09-07T22:54:04+00:00 Jia Jia physicalmtea@gmail.com 2026-08-28T08:57:21+00:00 e4f4761879a230aa59e569102a6ab9851847d833 When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB metadata are interpreted in a different address space. Keeping them across the transition can leave stale ring mappings in use. Clearing d->iotlb before taking the VQ locks also lets a worker observe a transient NULL d->iotlb and fall back to d->umem while translating a descriptor. Add a common vhost_clear_device_iotlb() helper for vhost-net and vhost-vsock. Take all VQ mutexes in index order before dropping the device-wide IOTLB, invalidate each VQ's cached ring access and metadata, clear pending IOTLB messages, and free the old table after the handoff. This serializes the transition with workers and prevents mixed address space mappings. On the first direct-to-IOTLB transition, invalidate the cached vring addresses. When an existing device IOTLB is replaced, preserve the GIOVA ring addresses and reset only the metadata cache. After clearing ACCESS_PLATFORM, userspace must configure the vring addresses for the new address mode. vhost_vq_invalidate_access() clears desc, avail, and used together. Treat the VQ as invalidated only when all three are NULL, since a single GIOVA address may legitimately be zero. Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API") Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jia Jia <physicalmtea@gmail.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260828085721.57816-1-physicalmtea@gmail.com> 
When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB
metadata are interpreted in a different address space. Keeping them
across the transition can leave stale ring mappings in use.

Clearing d->iotlb before taking the VQ locks also lets a worker observe
a transient NULL d->iotlb and fall back to d->umem while translating a
descriptor.

Add a common vhost_clear_device_iotlb() helper for vhost-net and
vhost-vsock. Take all VQ mutexes in index order before dropping the
device-wide IOTLB, invalidate each VQ's cached ring access and metadata,
clear pending IOTLB messages, and free the old table after the handoff.
This serializes the transition with workers and prevents mixed address
space mappings.

On the first direct-to-IOTLB transition, invalidate the cached vring
addresses. When an existing device IOTLB is replaced, preserve the
GIOVA ring addresses and reset only the metadata cache. After clearing
ACCESS_PLATFORM, userspace must configure the vring addresses for the
new address mode.

vhost_vq_invalidate_access() clears desc, avail, and used together.
Treat the VQ as invalidated only when all three are NULL, since a single
GIOVA address may legitimately be zero.

Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
Fixes: e13a6915a03f ("vhost/vsock: add IOTLB API support")
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jia Jia <physicalmtea@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260828085721.57816-1-physicalmtea@gmail.com>
vhost-scsi: clamp max_io_vqs module parameter 2026-09-07T22:54:04+00:00 Dongli Zhang dongli.zhang@oracle.com 2026-08-02T17:24:56+00:00 4e3ec5b1b427e02082e8b3491731f8c3bcf85c53 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. Keep accepting out-of-range values for compatibility, but clamp them in the module parameter setter and store the effective value. This preserves the existing behavior that invalid values do not make module loading or sysfs writes fail. It also makes reads report the value that will actually be used. With the parameter value kept in range, remove the duplicate validation from vhost_scsi_open(). Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260802172534.260047-3-dongli.zhang@oracle.com> 
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.

Keep accepting out-of-range values for compatibility, but clamp them in the
module parameter setter and store the effective value. This preserves the
existing behavior that invalid values do not make module loading or sysfs
writes fail. It also makes reads report the value that will actually be
used.

With the parameter value kept in range, remove the duplicate validation
from vhost_scsi_open().

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260802172534.260047-3-dongli.zhang@oracle.com>
vhost-scsi: use kvzalloc for vq array allocation 2026-09-07T22:54:03+00:00 Dongli Zhang dongli.zhang@oracle.com 2026-08-02T17:24:55+00:00 c952e607cb4aa3640e5ae07243d3f609dac94424 vhost_scsi_open() allocates one "struct vhost_scsi_virtqueue" for each virtqueue. With large max_io_vqs values, this array can require a high-order contiguous allocation and trigger a page allocator warning. hv# cat /sys/module/vhost_scsi/parameters/max_io_vqs 256 [ 766.075787] ------------[ cut here ]------------ [ 766.077030] WARNING: mm/page_alloc.c:5280 at __alloc_frozen_pages_noprof+0x32c/0x15c0, CPU#23: qemu-system-x86/5964 ... ... [ 766.080351] RIP: 0010:__alloc_frozen_pages_noprof+0x32c/0x15c0 ... ... [ 766.085813] Call Trace: [ 766.085969] <TASK> [ 766.086098] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.086365] ? context_struct_compute_av+0x38a/0x4b0 [ 766.086652] alloc_pages_mpol+0x9f/0x170 [ 766.086883] ___kmalloc_large_node+0xb6/0xd0 [ 766.087124] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.087389] __kmalloc_large_node_noprof+0x18/0xa0 [ 766.087655] __kmalloc_noprof+0x3a0/0x440 [ 766.087877] ? vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] [ 766.088162] vhost_scsi_open+0xcb/0x2d0 [vhost_scsi] [ 766.088449] misc_open+0x123/0x160 [ 766.088679] chrdev_open+0xb1/0x230 [ 766.088885] ? __pfx_chrdev_open+0x10/0x10 [ 766.089157] do_dentry_open+0x11a/0x470 [ 766.089389] vfs_open+0x29/0xf0 [ 766.089596] path_openat+0x7c0/0x1100 [ 766.089821] do_file_open+0xdd/0x190 [ 766.090032] ? srso_alias_return_thunk+0x5/0xfbef5 [ 766.090332] do_sys_openat2+0x7e/0x100 [ 766.090601] __x64_sys_openat+0x51/0xa0 [ 766.090857] do_syscall_64+0xfe/0x590 [ 766.091087] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 766.091411] RIP: 0033:0x7f9525a11fa6 The array does not require physical contiguity, so allocate it with kvzalloc_objs() and free it with kvfree(). Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260802172534.260047-2-dongli.zhang@oracle.com> 
vhost_scsi_open() allocates one "struct vhost_scsi_virtqueue" for each
virtqueue. With large max_io_vqs values, this array can require a
high-order contiguous allocation and trigger a page allocator warning.

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

[  766.075787] ------------[ cut here ]------------
[  766.077030] WARNING: mm/page_alloc.c:5280 at __alloc_frozen_pages_noprof+0x32c/0x15c0, CPU#23: qemu-system-x86/5964
... ...
[  766.080351] RIP: 0010:__alloc_frozen_pages_noprof+0x32c/0x15c0
... ...
[  766.085813] Call Trace:
[  766.085969]  <TASK>
[  766.086098]  ? srso_alias_return_thunk+0x5/0xfbef5
[  766.086365]  ? context_struct_compute_av+0x38a/0x4b0
[  766.086652]  alloc_pages_mpol+0x9f/0x170
[  766.086883]  ___kmalloc_large_node+0xb6/0xd0
[  766.087124]  ? srso_alias_return_thunk+0x5/0xfbef5
[  766.087389]  __kmalloc_large_node_noprof+0x18/0xa0
[  766.087655]  __kmalloc_noprof+0x3a0/0x440
[  766.087877]  ? vhost_scsi_open+0xcb/0x2d0 [vhost_scsi]
[  766.088162]  vhost_scsi_open+0xcb/0x2d0 [vhost_scsi]
[  766.088449]  misc_open+0x123/0x160
[  766.088679]  chrdev_open+0xb1/0x230
[  766.088885]  ? __pfx_chrdev_open+0x10/0x10
[  766.089157]  do_dentry_open+0x11a/0x470
[  766.089389]  vfs_open+0x29/0xf0
[  766.089596]  path_openat+0x7c0/0x1100
[  766.089821]  do_file_open+0xdd/0x190
[  766.090032]  ? srso_alias_return_thunk+0x5/0xfbef5
[  766.090332]  do_sys_openat2+0x7e/0x100
[  766.090601]  __x64_sys_openat+0x51/0xa0
[  766.090857]  do_syscall_64+0xfe/0x590
[  766.091087]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  766.091411] RIP: 0033:0x7f9525a11fa6

The array does not require physical contiguity, so allocate it with
kvzalloc_objs() and free it with kvfree().

Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260802172534.260047-2-dongli.zhang@oracle.com>