On Fri, May 2, 2014 at 9:42 AM, Paolo Bonzini <pbonz...@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