On Mon, Nov 02, 2026 at 09:37:40PM +0800, Yunye Zhao wrote:
> init_vq() reads the writable num_request_queues and poll_queues module
> parameters both at probe and when recreating virtqueues after suspend
> or reset. However, virtio-blk does not update the blk-mq hardware queue
> count or queue maps on restore.
>
> Increasing poll_queues can therefore remove the completion callback
> from a virtqueue still used for interrupt-driven I/O, leaving requests
> uncompleted. Reducing the effective request queue count through
> num_request_queues can instead leave existing hardware contexts
> indexing beyond the reallocated vblk->vqs array.
>
> Determine the virtqueue count and the split between interrupt-driven
> and polling queues once at probe, and reuse this layout when
> recreating the virtqueues. Changes to these module parameters then
> affect only subsequently probed devices.
>
> Fixes: 0989c41bed96 ("virtio-blk: add num_request_queues module parameter")
> Signed-off-by: Yunye Zhao <[email protected]>
> ---
> The functional fix was previously tested with QEMU 8.2.2 on
> 7be4bc52fd9e (v7.3-2415), covering:
>
> - PCI FLR after changing poll_queues from 0 to 1 or num_request_queues
> from 0 to 1 on a device with four request queues.
> - Normal and polled I/O across FLR with poll_queues=1 at probe,
> including a subsequent change of poll_queues to 0.
> - Device suspend/resume with pm_test=devices and state=freeze (not a
> full s2idle cycle), plus full S3 and S4 suspend/resume cycles.
I noticed that drivers/nvme/host/ allows the queues to change:
1. The hardware queue count can be different and the tagset is updated
with blk_mq_update_nr_hw_queues().
2. The module parameters are refreshed in nvme_setup_io_queues() and are
allowed to change across power management operations.
Please consider implementing more flexibile restore behavior in
virtio_blk that can toleration hardware queue count changes and module
parameter changes instead though.
However, this patch looks correct to me and can be merged IMO.
Reviewed-by: Stefan Hajnoczi <[email protected]>
