From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUhNQ-0003gC-Ez for qemu-devel@nongnu.org; Thu, 09 Jun 2011 11:42:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QUhNO-0004bh-KB for qemu-devel@nongnu.org; Thu, 09 Jun 2011 11:42:32 -0400 Received: from qmta02.westchester.pa.hmc1.comcast.net ([76.96.53.9]:45276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QUhNO-0004bW-4R for qemu-devel@nongnu.org; Thu, 09 Jun 2011 11:42:30 -0400 Message-ID: <4DF0E9D9.406@sundar.org> Date: Thu, 09 Jun 2011 08:42:17 -0700 From: Jagane Sundar MIME-Version: 1.0 References: <20110606165536.581119615@amt.cnet> <20110606165823.855959321@amt.cnet> <4DEF90E2.5080202@sundar.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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" , "dlaor@redhat.com" , "Jes.Sorensen@redhat.com" , Marcelo Tosatti , "qemu-devel@nongnu.org" , "avi@redhat.com" , "jdenemar@redhat.com" >> Hello Stefan, >> >> Can you expand on this some more? I have similar concerns for Livebackup. >> >> At the beginning of your paragraph, did you mean 'asynchronous I/O >> emulation' instead of 'synchronous I/O emulation'? >> >> Also, I don't understand the 'stack' construct that you refer to. When you >> say 'push a new context', are you talking about what happens when a new >> thread picks up a new async I/O req from the VM, and then proceeds to >> execute the I/O req? What is this stack that you refer to? >> >> Any design documents, code snippets that I can look, other pointers welcome. > See async.c. > Thanks - I will do so. > There is synchronous I/O emulation in block.c for BlockDrivers that > don't support .bdrv_read()/.bdrv_write() but only > .bdrv_aio_readv()/.bdrv_aio_writev(). The way it works is that it > pushes a new I/O context and then issues async I/O. Then it runs a > special event loop waiting for that I/O to complete. After the I/O > completes it pops the context again. > OK. This is the opposite of what I was thinking of. I was considering the code that emulates Async I/O using multiple threads. It sounds like the goal of this async.c mechanism is more than serializing all synchronous I/O requests, right? > The point of the context is that completions only get called for the > current context. Therefore callers of the synchronous I/O functions > don't need to worry that the state of the world might change during > their "synchronous" operation - only their own I/O operation can > complete. If a pending async I/O completes during synchronous I/O > emulation, its callback is not invoked until the bottom half (BH) is > called after the async context is popped. This guarantees that the > synchronous operation and its caller have completed before I/O > completion callbacks are invoked for pending async I/O. > OK. This might not be a problem for Livebackup, after all. Livebackup transparently interposes the async I/O offered by the driver. Hence the async.c mechanism is layered neatly above the async_block_driver+livebackup layer and should work correctly. I will take a closer look at this, and check for sanity... Thanks, Jagane