Re: [Qemu-devel] [PATCH 00/22] dataplane: use QEMU block layer

From: Stefan Hajnoczi <stefanha@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"Shergill, Gurinder" <gurinder.shergill@hp.com>,
	"Vinod, Chegu" <chegu_vinod@hp.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 00/22] dataplane: use QEMU block layer
Date: Fri, 2 May 2014 13:59:24 +0200	[thread overview]
Message-ID: <CAJSP0QXqZjjG8SsW6drUshFUyhM1cSqYYMWMzfufX7+VtOvr+g@mail.gmail.com> (raw)
In-Reply-To: <53634C60.1030003@redhat.com>

On Fri, May 2, 2014 at 9:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 01/05/2014 16:54, Stefan Hajnoczi ha scritto:
>
>> This patch series switches virtio-blk data-plane from a custom Linux AIO
>> request queue to the QEMU block layer.  The previous "raw files only"
>> limitation is lifted.  All image formats and protocols can now be used
>> with
>> virtio-blk data-plane.
>
>
> Yay!
>
>
>> I have already made block I/O throttling work in another AioContext and
>> will
>> send the series out next week.
>>
>> In order to keep this series reviewable, I'm holding back those patches
>> for
>> now.  One could say, "throttling" them.
>
>
> What's also missing is things like block jobs and live snapshots, right?
>
> Also, blockstats is not thread-safe and probably a couple other things but
> that's minor and easy to fix.

Yes, my plan for QEMU 2.1 is to handle the monitor commands that
aren't protected by bdrv_in_use().

The list of limitations is still fairly long:
1. No I/O throttling
2. Snapshot, blockstats, and other commands are not supported
3. No block jobs
4. No run-time NBD server
5. No hot unplug
6. virtio-blk scsi=on and config-wce=on are not supported

#3, #4, #5, and some of #2 are protected by the bdrv_in_use()
mechanism.  They continue to return an error after this patch series
just like they do today.

#1 is my first priority because it isn't protected by anything.  For
#2 I'm auditing monitor commands and protecting things on a
case-by-case basis.

Once everything up to and including #5 has been finished we can stop
using bdrv_in_use() in such a crude way.  Things will be protected by
aio_context_acquire/release() or other methods (I still have the
"switch this coroutine into that AioContext" up my sleeve for block
jobs and other hard cases).

Finally, #6 is where we have to answer the question "can virtio-blk
dataplane simply share the normal virtio-blk.c code?".  I want to
unify the dataplane and non-dataplane virtio-blk emulation so there is
only one code path that either runs in vcpu/mainloop or dataplane
IOThread.

Stefan