Re: [PULL 00/19] Migration patches

[Juan Quintela <quintela@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On Thu, 11 Jul 2019 at 11:56, Juan Quintela <quintela@redhat.com> wrote:
>>
>> The following changes since commit 6df2cdf44a82426f7a59dcb03f0dd2181ed7fdfa:
>>
>>   Update version for v4.1.0-rc0 release (2019-07-09 17:21:53 +0100)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/juanquintela/qemu.git tags/migration-pull-request
>>
>> for you to fetch changes up to 0b47e79b3d04f500b6f3490628905ec5884133df:
>>
>>   migration: allow private destination ram with x-ignore-shared
>> (2019-07-11 12:30:40 +0200)
>>
>> ----------------------------------------------------------------
>> Migration pull request
>>
>> ----------------------------------------------------------------
>
> Hi; this fails "make check" on aarch32 host (possibly a general
> 32-bit host issue, as this is the only 32-bit host I test on):
>
> MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
> tests/test-bitmap -m=quick -k --tap < /dev/null |
> ./scripts/tap-driver.pl --test-name="test-bitmap"
> **
> ERROR:/home/peter.maydell/qemu/tests/test-bitmap.c:39:check_bitmap_copy_with_offset:
> assertion failed (bmap1 == bmap2)
> Aborted
> ERROR - Bail out!
> ERROR:/home/peter.maydell/qemu/tests/test-bitmap.c:39:check_bitmap_copy_with_offset:
> assertion failed (bmap1 == bmap2)
> /home/peter.maydell/qemu/tests/Makefile.include:904: recipe for target
> 'check-unit' failed

Problem fixed, the code is right (TM), the test is wrong (also TM).

@@ -35,8 +36,8 @@ static void check_bitmap_copy_with_offset(void)
     /* Shift back 200 bits back */
     bitmap_copy_with_src_offset(bmap2, bmap3, 200, total);
 
-    g_assert_cmpmem(bmap1, total / sizeof(unsigned long),
-                    bmap2, total / sizeof(unsigned long));
+    g_assert_cmpmem(bmap1, total / BITS_PER_LONG,
+                    bmap2, total / BITS_PER_LONG);
 
     bitmap_clear(bmap1, 0, BMAP_SIZE);
     /* Set bits in bmap1 are 100-245 */


A long has 32 or 64 bits, not 4 or 8.

And why it worked in 64 bit?  Due to (bad?) luck.  64 bit is bigger, and
then it "overwrote" everypthing, and then it ends being zero on
destination by luck.

Resending.

Later, Juan.