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

[Kevin Wolf]

Am 09.02.2016 um 14:47 hat Stefan Hajnoczi geschrieben:
> 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.
> 
> 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)...

You would still have a monitor hang for half a minute.

And anyway, the only reasonable action to do on a timeout is to make the
image completetly unusable, with no option to resume operation on it
without restarting the VM because we don't know what state the image is
in.

That's a pretty large impact for something that qemu does automatically.
It would be much nicer if the monitor kept working all the time and the
management would actively tell qemu to give up on a given image.

Kevin

pgpqnPQXqBAtA.pgp
Description: PGP signature