qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 4/4] virtio-blk: add iothread-vq-mapping parameter


From: Kevin Wolf
Subject: Re: [PATCH v4 4/4] virtio-blk: add iothread-vq-mapping parameter
Date: Thu, 21 Dec 2023 14:10:20 +0100

Am 20.12.2023 um 14:47 hat Stefan Hajnoczi geschrieben:
> Add the iothread-vq-mapping parameter to assign virtqueues to IOThreads.
> Store the vq:AioContext mapping in the new struct
> VirtIOBlockDataPlane->vq_aio_context[] field and refactor the code to
> use the per-vq AioContext instead of the BlockDriverState's AioContext.
> 
> Reimplement --device virtio-blk-pci,iothread= and non-IOThread mode by
> assigning all virtqueues to the IOThread and main loop's AioContext in
> vq_aio_context[], respectively.
> 
> The comment in struct VirtIOBlockDataPlane about EventNotifiers is
> stale. Remove it.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

I'm looking at virtio_blk_dma_restart_cb/bh(). It seems to run all
queued requests in the iothread of the first vq, but when the requests
complete, they will push the result to their original vq.

Do we know that the dataplane isn't started and won't be started until
the requests complete? (I wouldn't expect so, because then moving to the
AioContext of the BlockBackend wouldn't have been necessary either.) Or
is there another reason why this is safe?

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]