From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRiyQ-0001KN-3E for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:29:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRiyH-0003H8-6o for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:29:46 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:40958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRiyG-0003Gp-EC for qemu-devel@nongnu.org; Thu, 03 Oct 2013 09:29:37 -0400 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 3 Oct 2013 23:29:29 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 35DBD2CE8040 for ; Thu, 3 Oct 2013 23:29:27 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r93DTEl27733674 for ; Thu, 3 Oct 2013 23:29:16 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r93DTPQl009328 for ; Thu, 3 Oct 2013 23:29:25 +1000 Message-ID: <524D7132.8070306@linux.vnet.ibm.com> Date: Thu, 03 Oct 2013 21:29:22 +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> In-Reply-To: <524D4853.5030907@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 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? > > 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