From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVIkF-0001KQ-Mw for qemu-devel@nongnu.org; Mon, 15 Feb 2016 07:59:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aVIkA-00085c-Kg for qemu-devel@nongnu.org; Mon, 15 Feb 2016 07:59:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aVIkA-00085M-FG for qemu-devel@nongnu.org; Mon, 15 Feb 2016 07:59:10 -0500 Date: Mon, 15 Feb 2016 13:59:08 +0100 From: Kevin Wolf Message-ID: <20160215125908.GE5244@noname.str.redhat.com> References: <20160208151722.GB3022@work-vm> <20160209134706.GE6510@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20160209134706.GE6510@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] lock-free monitor? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: armbru@redhat.com, xiecl.fnst@cn.fujitsu.com, "Dr. David Alan Gilbert" , qemu-devel@nongnu.org --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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? >=20 > 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). >=20 > bdrv_aio_cancel() can also hang but is mostly exposed to device > emulation, not the monitor. >=20 > 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. >=20 > The benefit of the timeout is that both monitor and device emulation > hangs are tackled. It also doesn't require monitor changes. >=20 > 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 --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWwcucAAoJEH8JsnLIjy/WZVYQALY24xs+QRdyIJ6TXMeagw9M zgutmYCcT3ahVbV/GWKJtBWJw9qFYWI1vEEU3Hp0XtJwgdDdeWyXP7rSw5IbOPbN Xty4P55553ZdlLUPCC/7zSbOvsGdtf4r3o/LhJaFx3IxcQQh9EpReJ7un68VsqLQ EyenK5XWp0ls7/I6JahzhvX15oPBQjeieXAPhJK5iHILKuOMwIOWw2M93fmhkVro GshzOPr7xPCk/vvfRteBDz4BgYIk4GGWkuUKSup3BtWhTkSpMn362HTHZoaPuXhM ap5+qZP6G4q+rvVxF2BM+yObC+oBIYn10m5odE6RFlOcpa+hUyqeFX2i2nbnon9+ lU4lpokTBvTcXrLAVnZefRjC0zKZQtVOk3TDiBsAQYQ4C1T6D+Kl4H7Sbby/BMmq ID2hZNGUhDHJw0fNwJpaE0xEmAsuGGyHy5YKqnXLvqjMDT5OIaroFYaLOv4c384J FalgVKZMGrgenwTFCzI4V5eJ9PDembieQwNgiIAdE+hshcwK7ChbeZG/5hfbfA6n XGU4A5o728+qs62tRFDW+P7teNc/J1r5DopHd6oDB/t7D0YFGZ7LDmyEq8197w+V 82oAO52AQzn+f0SDg4ffcz5pxStlglw9PKxbnVkTOUX/Vbq8saPFvN7g/u/aCWlw NAwKJnNBeKDy6OnXx6q2 =PhGI -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ--