Re: [Qemu-devel] lock-free monitor?

[Fam Zheng <famz@redhat.com>]

On Tue, 02/09 13:47, Stefan Hajnoczi wrote:
> On Mon, Feb 08, 2016 at 03:17:23PM +0000, Dr. David Alan Gilbert wrote:
> > Does this make sense to everyone else, or does anyone have any better
> > suggestions?
> 
> As a concrete example, any monitor command that calls bdrv_drain_all()
> can hang forever with the QEMU global mutex held if I/O requests are
> stuck (e.g. NFS mount is unreachable).
> 
> bdrv_aio_cancel() can also hang but is mostly exposed to device
> emulation, not the monitor.
> 
> One solution for these block layer functions is to add a timeout
> argument and let them return an error.  This way the monitor and device
> emulation do not hang forever.

Yes, there are a few places in block layer invoking aio_poll() in a loop
waiting for certain events, and a disconnected network link could make QEMU
hang. In these cases a timeout is a huge improvement.  Maybe we can mark the
BDS as "hanging" (-EIO is returned for all further requests) and let
bdrv_drain_all() return.

> 
> The benefit of the timeout is that both monitor and device emulation
> hangs are tackled.  It also doesn't require monitor changes.
> 
> I'm not sure who chooses the timeout value and which value makes sense
> (policy vs mechanism separation)...

Default to 30 seconds like Linux, and make it tunable through command line
options as well as QMP?

Fam