From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaFm1-0002hv-8n for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:45:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaFlz-0002gO-Qg for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:45:33 -0500 Received: from [199.232.76.173] (port=34489 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaFlz-0002gG-L8 for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:45:31 -0500 Received: from mx2.redhat.com ([66.187.237.31]:34035) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaFlz-0007fq-4V for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:45:31 -0500 Message-ID: <499DC4E1.6040006@redhat.com> Date: Thu, 19 Feb 2009 22:45:21 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] migration: adding migration to/from a file (v2) References: <499D4654.9000305@redhat.com> <499D652D.60803@codemonkey.ws> <499D8564.1070007@redhat.com> <499D8E05.2060207@codemonkey.ws> <499DADBB.4080008@redhat.com> <499DBB8E.6030705@codemonkey.ws> In-Reply-To: <499DBB8E.6030705@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Anthony Liguori wrote: > Uri Lublin wrote: >> Anthony Liguori wrote: >>> Uri Lublin wrote: >>>> Anthony Liguori wrote: >>>>> Uri Lublin wrote: >>>>>> >>>>>> Migration to file, uses migration-to-fd (supports live migration). >>>>>> Migration from file, uses qemu-fopen directly. >>>>> >>>>> Eh? Haven't we already talked about why this doesn't work? Maybe >>>>> there's a v3 that you meant to send? >>>>> >>>> >>>> Actually I do have a v3 which uses posix-aio-compat.c >>>> It's a much more complicated solution then just writing to a file >>>> though. >>>> Also I am not sure if I need to use a signal or not as the migration >>>> (to-fd) code is polling. And if I use signal should I use SIGUSR2 or >>>> a different one and use a pipe similar to block-raw-posix.c ? >>> >>> How is the migration code polling? It will attempt to do writes >>> until a write returns EAGAIN. At this point, it will wait for >>> notification that the more writes are available. Remember, migration >>> is a streaming protocol, not a random access, so it only makes sense >>> to have one outstanding request at a time. >>> >>> Your code would look something like: >>> >>> write() -> submit aio request >>> until aio completes, write returns EAGAIN >>> when aio completes, notify migration code that we are writable again >>> >> >> Basically that's what I've done in my v3. >> But since I fake EAGAIN, and the fd is writeable by select, the >> scenario is as follows: > > Oh, yes, this is a problem. You cannot use the existing migrate_fd code > unfortunately :-( > > Or maybe you can. If you change all instances of > qemu_set_fd_handler2() in migrate.c (in the migrate_fd_ routines) to > basically, s->set_fd_handler(), you can introduce a simple wrapper that > calls qemu_set_fd_handler2() for everything else, but for yourself, use > it as a mechanism to keep track of what the "writable" callback should > be. This is the callback you would invoke when the aio request completes. > So it looks simpler to just (v4 implementation) spawn a single writing thread, and use a pipe to "connect" it to the migration code (as the pipe supports non-blocking write). Would that be acceptable, or you prefer I'll implement s->set_fd_handler() ? In that case will need another thread and pipe for compatfd (qemu_signalfd), and allocate a buffer to hold the data until it's written (as the original buffer may change). Thanks, Uri.