On 31 July 2012 19:18, Igor Mitsyanko <i.mitsya...@samsung.com> wrote: > On 07/31/2012 06:56 PM, Peter Maydell wrote: >> On 27 July 2012 20:29, Igor Mitsyanko <i.mitsya...@samsung.com> 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...)
> 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. Having talked with Juan on IRC, I think the right thing here is to add support for transmitting bitmaps to vmstate, so we can say VMSTATE_BITMAP(wp_groups, SDState, wpgrps_size) and the vmstate code takes care of marshalling the bitmap to a standard wire format (probably 32 bit little endian) and back. I'll have a go at a patch... -- PMM
