From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaEEL-0005oY-DF for qemu-devel@nongnu.org; Thu, 19 Feb 2009 14:06:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaEEL-0005oM-0L for qemu-devel@nongnu.org; Thu, 19 Feb 2009 14:06:41 -0500 Received: from [199.232.76.173] (port=48764 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaEEK-0005oA-Os for qemu-devel@nongnu.org; Thu, 19 Feb 2009 14:06:40 -0500 Received: from mx2.redhat.com ([66.187.237.31]:36000) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaEEK-0001NY-4r for qemu-devel@nongnu.org; Thu, 19 Feb 2009 14:06:40 -0500 Message-ID: <499DADBB.4080008@redhat.com> Date: Thu, 19 Feb 2009 21:06:35 +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> In-Reply-To: <499D8E05.2060207@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: >>>> >>>> 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: file_write (s->write of fd-migration) returns EAGAIN migrate_fd_put_buffer calls qemu_set_fd_handler2 with migrate_fd_put_notify upon the next main_loop_wait fd is found writable and migrate_fd_put_notify is called. qemu_file_put_notify is called. buffered_put_buffer is called. buffered_flush is called. s->freeze_output=0 migrate_fd_put_buffer is called file_write is called again -- here I can check if previous aio write finished. >> >> Your concern in the previous patch was that write() to a regular file >> might block. That's why I'm calling select before calling write. Do >> you think select will mark the fd as writeable but write would still >> block ? > > select() doesn't help. It will return that the file descriptor is > writable and then the subsequent write will block. Sure looks like a bug. I'll send my v3 using posix-aio-compat for review soon. Thanks, Uri.