From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWu5t-0004F8-N7 for qemu-devel@nongnu.org; Wed, 15 Jun 2011 13:41:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QWu5r-00063U-7b for qemu-devel@nongnu.org; Wed, 15 Jun 2011 13:41:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QWu5q-00062u-6s for qemu-devel@nongnu.org; Wed, 15 Jun 2011 13:41:30 -0400 Date: Wed, 15 Jun 2011 13:59:04 -0300 From: Marcelo Tosatti Message-ID: <20110615165904.GA15978@amt.cnet> References: <20110606165536.581119615@amt.cnet> <20110606165823.855959321@amt.cnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [patch 6/7] QEMU live block copy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, Jes.Sorensen@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com, jdenemar@redhat.com On Tue, Jun 07, 2011 at 01:15:02PM +0100, Stefan Hajnoczi wrote: > On Mon, Jun 6, 2011 at 5:55 PM, Marcelo Tosatti wrote: > > I haven't reviewed this whole patch yet, but comments below. > > This patch, like image streaming, may hit deadlocks due to synchronous > I/O emulation. I discovered this problem when working on image > streaming and it should be solved by getting rid of the asynchronous > context concept. The problem is that async I/O emulation will push a > new context, preventing existing requests to complete until the > current context is popped again. If the image format has dependencies > between requests (e.g. QED allocating writes are serialized), then > this leads to deadlock because the new request cannot complete until > the old one does, but the old one needs to wait for the context to be > popped. I think you are not affected by the QED allocating write case > since the source image is only read, not written, by live block copy. > But you might encounter this problem in other places. I see. This should be fixed in the context push/pop logic (or something equivalent), as you mention. Fixed other comments, thanks.