From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwH2B-00061F-C5 for qemu-devel@nongnu.org; Tue, 31 Jul 2012 14:19:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwH2A-0003Bq-EE for qemu-devel@nongnu.org; Tue, 31 Jul 2012 14:19:07 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:15048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwH2A-0003Bh-1k for qemu-devel@nongnu.org; Tue, 31 Jul 2012 14:19:06 -0400 Received: from eusync4.samsung.com (mailout4.w1.samsung.com [210.118.77.14]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0M81009JIEWU7IB0@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 31 Jul 2012 19:19:42 +0100 (BST) Received: from [106.109.9.180] by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0M81004EQEVPBR10@eusync4.samsung.com> for qemu-devel@nongnu.org; Tue, 31 Jul 2012 19:19:03 +0100 (BST) Message-id: <50182191.6000808@samsung.com> Date: Tue, 31 Jul 2012 22:18:57 +0400 From: Igor Mitsyanko MIME-version: 1.0 References: <1343417387-13953-1-git-send-email-i.mitsyanko@samsung.com> <1343417387-13953-9-git-send-email-i.mitsyanko@samsung.com> In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V4 08/12] hw/sd.c: add SD card save/load support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: kwolf@redhat.com, benoit.canet@gmail.com, wdongxu@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, e.voevodin@samsung.com, qemu-devel@nongnu.org, armbru@redhat.com, andrew.zaborowski@intel.com, kyungmin.park@samsung.com, pbonzini@redhat.com On 07/31/2012 06:56 PM, Peter Maydell wrote: > On 27 July 2012 20:29, Igor Mitsyanko wrote: >> + VMSTATE_BUFFER_MULTIPLY(wp_groups, SDState, 1, NULL, 0, wpgrps_size, >> + sizeof(unsigned long)), > > Isn't this trying to use wpgrps_size as the number of unsigned longs in > the bitmap, when it's actually the size of the bitmap in bits? > > (Does this correctly work in migration between 32 and 64 bit systems > where 'unsigned long' is a different size? How about between a little > endian 32 bit system and a big endian 64 bit system? I don't know > enough about the vmstate macros to be confident here...) > > -- PMM > > You're right, bitmap_new() can allocated buffers of different size for the same number of bits but different sizeof(long) value. Maybe always align allocated buffer size to 8 byte? Endianess seems like even bigger issue.. Looks like we need to think of something else here.