Re: [Qemu-devel] [PULL 09/27] migration: calculate vCPU blocktime on dst side

[Dr. David Alan Gilbert]

* Max Reitz (address@hidden) wrote:
> On 2018-01-15 12:52, Juan Quintela wrote:
> > From: Alexey Perevalov <address@hidden>
> > 
> > This patch provides blocktime calculation per vCPU,
> > as a summary and as a overlapped value for all vCPUs.
> > 
> > This approach was suggested by Peter Xu, as an improvements of
> > previous approch where QEMU kept tree with faulted page address and cpus 
> > bitmask
> > in it. Now QEMU is keeping array with faulted page address as value and vCPU
> > as index. It helps to find proper vCPU at UFFD_COPY time. Also it keeps
> > list for blocktime per vCPU (could be traced with page_fault_addr)
> > 
> > Blocktime will not calculated if postcopy_blocktime field of
> > MigrationIncomingState wasn't initialized.
> > 
> > Signed-off-by: Alexey Perevalov <address@hidden>
> > Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> > Reviewed-by: Juan Quintela <address@hidden>
> > Signed-off-by: Juan Quintela <address@hidden>
> > ---
> >  migration/postcopy-ram.c | 143 
> > ++++++++++++++++++++++++++++++++++++++++++++++-
> >  migration/trace-events   |   5 +-
> >  2 files changed, 146 insertions(+), 2 deletions(-)
> 
> For me, this breaks compilation with clang -m32:
> 
>   LINK    x86_64-softmmu/qemu-system-x86_64
> ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_begin':
> /home/maxx/projects/qemu/migration/postcopy-ram.c:599: undefined
> reference to `__atomic_exchange_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:600: undefined
> reference to `__atomic_exchange_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:609: undefined
> reference to `__atomic_exchange_8'
> ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_end':
> /home/maxx/projects/qemu/migration/postcopy-ram.c:665: undefined
> reference to `__atomic_fetch_add_8'
> /home/maxx/projects/qemu/migration/postcopy-ram.c:686: undefined
> reference to `__atomic_fetch_add_8'
> 
> Am I doing something wrong?

Hmm I also see that with clang on 32bit (gcc is fine);
the problem is the postcopy blocktime stuff is doing some 64bit
atomics, which you can never be sure 32bit will support.

Dave

> Max
> 



--
Dr. David Alan Gilbert / address@hidden / Manchester, UK