On Fri, Jun 14, 2013 at 10:12:00AM -0400, Paolo Bonzini wrote: > Il 14/06/2013 05:48, Stefan Hajnoczi ha scritto: > > Associating a BlockDriverState with a single AioContext is not flexible > > enough. Once we make BlockDriverState thread-safe, it will be possible > > to call bdrv_*() functions from multiple event loops. > > I'm afraid that this is trading some pain now (converting > qemu_bh_new/qemu_set_fd_handler to aio_bh_new/aio_set_fd_handler) for > more pain later (having to make BDS thread-safe). There aren't that > many (~40) in block layer code. > > Making BlockDriverState thread-safe is hard, it is much simpler to run > all the BlockDriverState code in the AioContext thread itself. > > There are some things that cannot (basically monitor commands and other > places that are currently using bdrv_drain_all) but they can simply take > a "big AioContext lock".
I don't like a big AioContext lock that stops the event loop because we need to support a M:N device:iothread model where stopping an event loop means artificially stopping other devices too. Maybe it's workable though since the only commands that would take an AioContext lock are rare and shouldn't impact performance. I guess then it comes down to robustness if a hung NFS mount can affect the entire VM instead of just hanging an emulated disk device. Still, I have tried the lock approach and agree it is hard. I'll experiment some more and hopefully come up with something that handles block jobs and the run-time NBD server. Stefan
