Re: [Qemu-devel] Some thoughts about per-queue iothreads in VirtIOBlock

[Stefan Hajnoczi]

On Tue, Mar 20, 2018 at 07:30:04PM +0300, Edgar Kaziakhmedov wrote:
> 
> On 3/20/18 6:34 PM, Paolo Bonzini wrote:
> > On 20/03/2018 15:45, Edgar Kaziakhmedov wrote:
> > 
> > > As I understood from
> > > Stefan description, it is expected to change significantly
> > > the approach we use to interact with BlockDriverState.
> > I don't think the change is very large actually, at least for on-disk
> > devices.  I haven't yet considered network devices such as libiscsi or ceph.
> 
> Well, in that case, I will keep working on per-queue iothreads with an
> existing interface.
> I asked because it might be reasonable to create BlockBackend device for
> each queue context and
> use them independently to avoid some additional locks and synchronization.
> On the other hand, it can lead to multiple
> opening of the same image, but as I said it doesn't seem to be a problem for
> the simplest formats such as raw.

The special case for raw approach is not suitable for upstream QEMU.
It's what we started with in -device virtio-blk,x-data-plane=on (see the
old dataplane implementation in QEMU v1.4).

It took a lot of work to make the IOThread use the QEMU block layer
instead of a special case code path for raw.

Currently QEMU is not that far away from being able to use
BlockDriverState from multiple threads for multiqueue.

Paolo, can you share your current progress and pointers to what needs to
be done next?  Maybe Edgar can help complete the work.

Stefan

signature.asc
Description: PGP signature