From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaF9v-0006g8-PP for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:06:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaF9t-0006cR-L0 for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:06:11 -0500 Received: from [199.232.76.173] (port=40941 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaF9t-0006aq-8x for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:06:09 -0500 Received: from qw-out-1920.google.com ([74.125.92.145]:65428) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaF9r-0002Ra-EM for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:06:07 -0500 Received: by qw-out-1920.google.com with SMTP id 4so176603qwk.4 for ; Thu, 19 Feb 2009 12:06:06 -0800 (PST) Message-ID: <499DBB8E.6030705@codemonkey.ws> Date: Thu, 19 Feb 2009 14:05:34 -0600 From: Anthony Liguori 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> In-Reply-To: <499DADBB.4080008@redhat.com> 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: Uri Lublin Cc: qemu-devel@nongnu.org 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. > Sure looks like a bug. I wish! It's Unix suckiness. Regards, Anthony Liguori > I'll send my v3 using posix-aio-compat for review soon. > > Thanks, > Uri.