Am 13.02.2025 um 19:00 hat Stefan Hajnoczi geschrieben: > Previously the ctrl virtqueue was handled in the AioContext where SCSI > requests are processed. When IOThread Virtqueue Mapping was added things > become more complicated because SCSI requests could run in other > AioContexts. > > Simplify by handling the ctrl virtqueue in the main loop where reset > operations can be performed. Note that BHs are still used canceling SCSI > requests in their AioContexts but at least the mean loop activity > doesn't need BHs anymore. > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
> diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c > index 6bb368c8a5..2d37fa6712 100644 > --- a/hw/scsi/virtio-scsi-dataplane.c > +++ b/hw/scsi/virtio-scsi-dataplane.c > @@ -73,6 +73,12 @@ void virtio_scsi_dataplane_setup(VirtIOSCSI *s, Error > **errp) > s->vq_aio_context[i] = ctx; > } > } > + > + /* > + * Always handle the ctrl virtqueue in the main loop thread where device > + * resets can be performed. > + */ > + s->vq_aio_context[0] = qemu_get_aio_context(); > } Hmm... So now it's mandatory to provide a mapping for the control queue if you're using iothread virtqueue mappings, but it's always ignored? Looks like another reason why we should change the interface to have separate properties for the command queues and the event queue (and no property for the control queue if we want it to be fixed). In fact, maybe just tie the event queue to the main loop, too? Kevin