From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRj6V-0002JL-6s for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:38:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRj6M-0006Sp-1B for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:38:07 -0400 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:56932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRj6L-0006SC-B6 for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:37:57 -0400 Received: from /spool/local by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 3 Oct 2013 19:07:49 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 15A0B394004E for ; Thu, 3 Oct 2013 19:07:29 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r93DbhHA48693462 for ; Thu, 3 Oct 2013 19:07:44 +0530 Received: from d28av04.in.ibm.com (localhost [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r93Dbin5015190 for ; Thu, 3 Oct 2013 19:07:44 +0530 Message-ID: <524D7325.7000403@linux.vnet.ibm.com> Date: Thu, 03 Oct 2013 21:37:41 +0800 From: Lei Li MIME-Version: 1.0 References: <1380119568-5530-1-git-send-email-lilei@linux.vnet.ibm.com> <5242FAE8.6030807@redhat.com> <52442C16.7000200@linux.vnet.ibm.com> <524CEC9A.6050602@linux.vnet.ibm.com> <524D2985.8050301@redhat.com> <524D46E0.7010002@linux.vnet.ibm.com> <524D4853.5030907@redhat.com> <524D7132.8070306@linux.vnet.ibm.com> <524D726E.9080501@redhat.com> In-Reply-To: <524D726E.9080501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/8 RFC] migration: Introduce side channel for RAM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aarcange@redhat.com, quintela@redhat.com, mdroth@linux.vnet.ibm.com, mrhines@linux.vnet.ibm.com, qemu-devel@nongnu.org, anthony@codemonkey.ws, lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com On 10/03/2013 09:34 PM, Paolo Bonzini wrote: > Il 03/10/2013 15:29, Lei Li ha scritto: >> On 10/03/2013 06:34 PM, Paolo Bonzini wrote: >>> Il 03/10/2013 12:28, Lei Li ha scritto: >>>> The load_hook callback is only be called if the RAM_SAVE_FLAG_HOOK is >>>> received. >>>> To check this flags, it means there would be a check action first in >>>> unix_accept_incoming_migration(), like: >>>> >>>> f = qemu_fopen_pipe(c, "rb"); >>>> flags = qemu_get_be64(f); >>>> if (flags == RAM_SAVE_FLAG_HOOK) { >>>> load_hook(); >>>> ... >>>> } >>>> >>>> Otherwise, the incoming side has no idea whether the special 8-bytes >>>> record >>>> (RAM_SAVE_FLAG_HOOK) is sent. >>> No, ram_load is taking care of checking for RAM_SAVE_FLAG_HOOK. If >>> before_iterate writes the 8 bytes (followed by passing the fd for the >>> pipe's read-side via SCM_RIGHTS), ram_load will call load_hook before it >>> loads any page and load_hook will fetch the fd. >> If let ram_load take care of checking for RAM_SAVE_FLAG_HOOK, then in >> unix_accept_incoming_migration(), how to decide which QEMUFile should >> be opened? Since there would be two types of QEMUFile, one is the original >> QEMUFile opened by qemu_fopen_socket() for normal Unix migration, the >> other is opened by qemu_fopen_pipe() for unix-page-flipping migration. >> >> Or, were you suggesting replace this qemu_fopen_socket() with the >> qemu_fopen_pipe(), which also contain the copy of the QEMUFile code for >> Unix sockets? > Yes (though I'd call it qemu_fopen_socket_local() or something like that). > > On the incoming side, if non-page-flipping was enabled you will use the > normal RAM loading code, if page-flipping was enabled you will get > load_hook calls. Ah, I see. :) qemu_fopen_socket_local() sounds good, thanks! > Paolo > >>> Subsequent calls to load_hook will match data written by the sender's >>> save_page hook (so they contain a RAM address, with the 4k page data >>> sent on the pipe). >>> >>> Paolo >>> >> -- Lei