From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsZZl-00036t-Kc for qemu-devel@nongnu.org; Fri, 28 Jun 2013 10:23:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsZZi-00035f-IZ for qemu-devel@nongnu.org; Fri, 28 Jun 2013 10:23:01 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:56189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsZZi-00035b-Bm for qemu-devel@nongnu.org; Fri, 28 Jun 2013 10:22:58 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Jun 2013 08:22:57 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id A12251FF0020 for ; Fri, 28 Jun 2013 08:17:33 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5SEMmA2077926 for ; Fri, 28 Jun 2013 08:22:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5SEMkYt007004 for ; Fri, 28 Jun 2013 08:22:48 -0600 Message-ID: <51CD9C31.5040200@linux.vnet.ibm.com> Date: Fri, 28 Jun 2013 10:22:41 -0400 From: "Michael R. Hines" MIME-Version: 1.0 References: <1372373098-5877-1-git-send-email-mrhines@linux.vnet.ibm.com> <1372373098-5877-4-git-send-email-mrhines@linux.vnet.ibm.com> <51CD8E44.2090201@linux.vnet.ibm.com> <51CD9706.1000804@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/6] rdma: core logic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: aliguori@us.ibm.com, quintela@redhat.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com, chegu_vinod@hp.com, knoel@redhat.com On 06/28/2013 10:07 AM, Peter Maydell wrote: > On 28 June 2013 15:00, Michael R. Hines wrote: >> On 06/28/2013 09:28 AM, Peter Maydell wrote: >>>> Is endianess for the data a big issue when you are assume the migration >>>> is happening across identical CPU architectures? >>> Well: >>> * is that a reasonable assumption? (why?) >> >> I would yes, because we're dealing raw guest RAM. >> Migration of memory would not work across a different architecture >> (particularly page tables - which would need to be canonicalized >> and de-canonicalized). > Raw guest RAM is fine, because the VM at the destination > will (by definition) be running a guest of the same endianness. > However it looks like in this code you have host (QEMU) > code looking into the guest RAM, and the guest and host > might not have the same endianness. (The easy way for them > to be different is if you're using TCG rather than KVM; > alternatively you might be running a big-endian VM inside KVM > with a little-endian QEMU controlling it, if your architecture > supports that.) Alright, I see. I guess the moral of the story is that I should not make any architecture assumptions about *any* part of QEMU, then. I'll add the remaining byte-swap routines for safety to the patch before I sent out the next patch series. >>> * if you try this on some setup where it's not true, do we >>> fail helpfully or obscurely? >> Shouldn't a check like that occur before the migration actually begins? >> Is this specific to RDMA? > Normal migration works fine for TCG because it doesn't depend on > the endianness of the host vs the guest -- everything on the > wire is in big-endian format and we byteswap field values as > we marshall them. Guest RAM itself is just sent as a bag of bytes > (conceptually speaking, anyway). Understood. - Michael