From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRg9j-00058k-Hl for qemu-devel@nongnu.org; Thu, 03 Oct 2013 06:29:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRg9Y-0005h7-RV for qemu-devel@nongnu.org; Thu, 03 Oct 2013 06:29:15 -0400 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:59936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRg9Y-0005gW-2N for qemu-devel@nongnu.org; Thu, 03 Oct 2013 06:29:04 -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 15:58:55 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 3818C3940057 for ; Thu, 3 Oct 2013 15:58:37 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r93AVIkT22478968 for ; Thu, 3 Oct 2013 16:01:19 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r93ASqA9005983 for ; Thu, 3 Oct 2013 15:58:52 +0530 Message-ID: <524D46E0.7010002@linux.vnet.ibm.com> Date: Thu, 03 Oct 2013 18:28:48 +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> In-Reply-To: <524D2985.8050301@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, qemu-devel@nongnu.org, mrhines@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, anthony@codemonkey.ws, lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com On 10/03/2013 04:23 PM, Paolo Bonzini wrote: > Il 03/10/2013 06:03, Lei Li ha scritto: >> Hi Paolo, >> >> When debugging the code, I realized that this problem might still >> exist. In the incoming part, it will qemu_fopen_pipe() in >> unix_accept_incoming_migration first to enable the load_hook >> callback, the check action of this RAM_SAVE_FLAG_HOOK flags would >> lead to 8 bytes taken. Turns out, it will break normal unix >> migration (without unix-page-flipping), because no matter normal unix >> migration or unix-page-flipping migration, the incoming side has to >> check this 8-byes flags first to decide whether the load_hook is >> called, and normal unix migration did not send this 8-byte flags. > Why is the load_hook callback being called at all without page flipping? > Without page flipping, the before_iterate and save_page hook will > return immediately (or depending on your code they may never be called), > so the RAM_SAVE_FLAG_HOOK will never be written to the Unix socket. 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. In unix-page-flipping migration, it is OK. Without page flipping, since the RAM_SAVE_FLAG_HOOK is not be written to the Unix socket, but the incoming side will still check it, that will lead to the unexpected 8-bytes taken. If the logic and the way to deal with it above is correct according to your suggestion, how about: 1) Use another Unix socket to deal with this flags and pipe fd passing. or 2) Use a new prefix URI for the incoming. > >> I wonder if I didn't understand your suggestion correctly? > Perhaps you want to discuss this tomorrow morning on #qemu? I joined the #qemu channel just now, seems you were not there. I guess it's your lunch time right now. :) > > Paolo > -- Lei