V4->V3
- common helper was introduced and sanity check for
probable time jumps (comment from David)
V2->V3
- use UINT32_MAX instead of 0xffffffff (comment from Philippe)
- use lelative time to avoid milliseconds overflow in uint32
(comment from David)
V2->V1
This is a second version:
- comment from David about casting
David was right, I tried to find it in standard, but it was implicitly
described for me, so part of standard:
1. When a value with integer type is converted to another integer
type other than _Bool, if the value can be represented by the new
type, it is unchanged.
2. Otherwise, if the new type is unsigned, the value is converted
by repeatedly adding or subtracting one more than the maximum value
that can be represented in the new type until the value is in the
range of the new type.
Initial message:
It was a problem with 64 atomics on ppc in migration/postcopy-ram.c reported by
Philippe Mathieu-Daudé <f4...@amsat.org>.
Tested in Debian on qemu-system-ppc and in Ubuntu16.04 on i386.
This commit is based on commit afd3397a8149d8b645004e459bf2002d78f5e267
Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into
staging
but with all necessary commit reverted in
ee86981bda9ecd40c8daf81b7307b1d2aff68174
Alexey Perevalov (1):
migration: change blocktime type to uint32_t
hmp.c | 4 ++--
migration/postcopy-ram.c | 52 ++++++++++++++++++++++++++++--------------------
migration/trace-events | 4 ++--
qapi/migration.json | 4 ++--
4 files changed, 36 insertions(+), 28 deletions(-)
--
2.7.4
