Re: [Qemu-devel] [PULL 00/14] Migration pull request

[Peter Maydell]

On 3 January 2018 at 09:38, Juan Quintela <address@hidden> wrote:
> Hi
>
> This are the changes for migration that are already reviewed.
>
> Please, apply.
>
> Later, Juan.
>
>
> The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:
>
>   Merge remote-tracking branch 
> 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 
> 00:11:36 +0000)
>
> are available in the Git repository at:
>
>   git://github.com/juanquintela/qemu.git tags/migration/20180103
>
> for you to fetch changes up to 8a18afdcd8d2d6ab31f9de89d2f20fdadb89beb8:
>
>   migration: finalize current_migration object (2018-01-03 09:28:56 +0100)
>
> ----------------------------------------------------------------
> migration/next for 20180103
>

This fails to build on 32-bit systems:

/home/peter.maydell/qemu/migration/postcopy-ram.c: In function
'mark_postcopy_blocktime_begin':
/home/peter.maydell/qemu/migration/postcopy-ram.c:658:54: error: cast
to pointer from integer of different size
[-Werror=int-to-pointer-cast]
     already_received = ramblock_recv_bitmap_test(rb, (void *)addr);
                                                      ^

Keeping pointers in uint64_t and casting all over the place
looks like the wrong thing -- using the uintptr_t type will
likely make things cleaner.

This also looks suspicious:

    atomic_xchg__nocheck(&dc->last_begin, now_ms);
    atomic_xchg__nocheck(&dc->page_fault_vcpu_time[cpu], now_ms);
    atomic_xchg__nocheck(&dc->vcpu_addr[cpu], addr);

because atomic operations on types larger than the host pointer
size are not portable to all architectures. This should probably
use the atomic_cmpxchg(), not __nocheck, because the latter
bypasses the build time assert for this problem and turns a
"fails on any 32-bit host" into "fails obscurely on some
architectures only".

thanks
-- PMM