docs/devel/{migration.txt => migration.rst} | 484 +++++++++++++++-------------
hmp.c | 37 ++-
include/migration/misc.h | 1 +
migration/migration.c | 423 ++++++++++++++----------
migration/migration.h | 35 ++
migration/postcopy-ram.c | 258 ++++++++++++++-
migration/ram.c | 3 +-
migration/socket.c | 4 +-
migration/trace-events | 6 +-
qapi/migration.json | 37 ++-
scripts/analyze-migration.py | 4 +
tests/migration-test.c | 19 +-
vl.c | 1 +
13 files changed, 895 insertions(+), 417 deletions(-)
rename docs/devel/{migration.txt => migration.rst} (58%)
Hi
- rebase on top of lastest
- fix compilation on 32bit machines
- add Peter Xu cleanups
Please, apply.
The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93:
Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000)
are available in the Git repository at:
git://github.com/juanquintela/qemu.git tags/migration/20180115
for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f:
migration: remove notify in fd_error (2018-01-15 12:48:13 +0100)
----------------------------------------------------------------
migration/next for 20180115
----------------------------------------------------------------
Alexey Perevalov (6):
migration: introduce postcopy-blocktime capability
migration: add postcopy blocktime ctx into MigrationIncomingState
migration: calculate vCPU blocktime on dst side
migration: postcopy_blocktime documentation
migration: add blocktime calculation into migration-test
migration: add postcopy total blocktime into query-migrate
Dr. David Alan Gilbert (2):
docs: Convert migration.txt to rst
migration: Guard ram_bytes_remaining against early call
Juan Quintela (4):
migration: Use proper types in json
migration: print features as on off
migration: free addr in the same function that we created it
migration: free result string
Laurent Vivier (1):
migration: fix analyze-migration.py script with radix table
Peter Xu (13):
migration: assert colo instead of check
migration: qemu_savevm_state_cleanup() in cleanup
migration: remove "enable_colo" var
migration: split use of MigrationState.total_time
migration: move vm_old_running into global state
migration: introduce downtime_start
migration: introduce migrate_calculate_complete
migration: use switch at the end of migration
migration: cleanup stats update into function
migration: major cleanup for migrate iterations
migration: put the finish part into a new function
migration: remove some block_cleanup_parameters()
migration: remove notify in fd_error
Vladimir Sementsov-Ogievskiy (1):
migration: finalize current_migration object
docs/devel/{migration.txt => migration.rst} | 484 +++++++++++++++-------------
hmp.c | 37 ++-
include/migration/misc.h | 1 +
migration/migration.c | 423 ++++++++++++++----------
migration/migration.h | 35 ++
migration/postcopy-ram.c | 258 ++++++++++++++-
migration/ram.c | 3 +-
migration/socket.c | 4 +-
migration/trace-events | 6 +-
qapi/migration.json | 37 ++-
scripts/analyze-migration.py | 4 +
tests/migration-test.c | 19 +-
vl.c | 1 +
13 files changed, 895 insertions(+), 417 deletions(-)
rename docs/devel/{migration.txt => migration.rst} (58%)
On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: > Hi > - rebase on top of lastest > - fix compilation on 32bit machines > - add Peter Xu cleanups > > Please, apply. > > The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93: > > Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000) > > are available in the Git repository at: > > git://github.com/juanquintela/qemu.git tags/migration/20180115 > > for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f: > > migration: remove notify in fd_error (2018-01-15 12:48:13 +0100) > > ---------------------------------------------------------------- > migration/next for 20180115 Applied, thanks. -- PMM
On 01/15/2018 01:14 PM, Peter Maydell wrote: > On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: >> Hi >> - rebase on top of lastest >> - fix compilation on 32bit machines >> - add Peter Xu cleanups >> >> Please, apply. >> >> The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93: >> >> Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000) >> >> are available in the Git repository at: >> >> git://github.com/juanquintela/qemu.git tags/migration/20180115 >> >> for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f: >> >> migration: remove notify in fd_error (2018-01-15 12:48:13 +0100) >> >> ---------------------------------------------------------------- >> migration/next for 20180115 > > Applied, thanks. We have armel/armhf/powerpc hosts failing since this pull due to commit 3be98be4e9f. Those target are currently tested on Shippable CI, eventually adding an IRC bot we could notice. I know companies using QEMU system in embedded armel/armhf hosts, I don't know about the ppc32 hosts. This is however unlikely the migration features are used there. If 64bit atomic op are required for migration (performance/security) but not on 32bit system, one way to fix it could be to have the migration code being optional... so we can disable it on 32bit hosts. Regards, Phil.
On 19 January 2018 at 16:27, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > We have armel/armhf/powerpc hosts failing since this pull due to commit > 3be98be4e9f. > > Those target are currently tested on Shippable CI, eventually adding an > IRC bot we could notice. > > I know companies using QEMU system in embedded armel/armhf hosts, I > don't know about the ppc32 hosts. > This is however unlikely the migration features are used there. I have ppc64 and armhf in my test set, so clearly they don't all fail all the time. What are the failure symptoms ? thanks -- PMM
On 01/19/2018 01:34 PM, Peter Maydell wrote:
> On 19 January 2018 at 16:27, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> We have armel/armhf/powerpc hosts failing since this pull due to commit
>> 3be98be4e9f.
>>
>> Those target are currently tested on Shippable CI, eventually adding an
>> IRC bot we could notice.
>>
>> I know companies using QEMU system in embedded armel/armhf hosts, I
>> don't know about the ppc32 hosts.
>> This is however unlikely the migration features are used there.
>
> I have ppc64 and armhf in my test set, so clearly they don't all
> fail all the time. What are the failure symptoms ?
I misread Shippable report with the report trying to fix this,
so indeed on /master, only ppc32 is broken, the symtom is linking failing:
https://app.shippable.com/github/qemu/qemu/runs/665/10/console
../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_end':
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:717: undefined
reference to `__atomic_fetch_add_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:738: undefined
reference to `__atomic_fetch_add_8'
../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_begin':
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:651: undefined
reference to `__atomic_exchange_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:652: undefined
reference to `__atomic_exchange_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:661: undefined
reference to `__atomic_exchange_8'
collect2: error: ld returned 1 exit status
Makefile:193: recipe for target 'qemu-system-ppc' failed
make[1]: *** [qemu-system-ppc] Error 1
Makefile:391: recipe for target 'subdir-ppc-softmmu' failed
make: *** [subdir-ppc-softmmu] Error 2
../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_end':
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:717: undefined
reference to `__atomic_fetch_add_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:738: undefined
reference to `__atomic_fetch_add_8'
../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_begin':
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:651: undefined
reference to `__atomic_exchange_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:652: undefined
reference to `__atomic_exchange_8'
/root/src/github.com/qemu/qemu/migration/postcopy-ram.c:661: undefined
reference to `__atomic_exchange_8'
collect2: error: ld returned 1 exit status
Makefile:193: recipe for target 'qemu-system-ppcemb' failed
make[1]: *** [qemu-system-ppcemb] Error 1
Makefile:391: recipe for target 'subdir-ppcemb-softmmu' failed
make: *** [subdir-ppcemb-softmmu] Error 2
The armel/armhf failures are when I apply this patch:
http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg04873.html
In file included from
/root/src/github.com/philmd/qemu/include/qemu/osdep.h:36:0,
from migration/postcopy-ram.c:19:
migration/postcopy-ram.c: In function 'mark_postcopy_blocktime_begin':
/root/src/github.com/philmd/qemu/include/qemu/compiler.h:86:30: error:
static assertion failed: "not expecting: sizeof(*&dc->last_begin) >
ATOMIC_REG_SIZE"
#define QEMU_BUILD_BUG_ON(x) _Static_assert(!(x), "not expecting: " #x)
^
/root/src/github.com/philmd/qemu/include/qemu/atomic.h:183:5: note: in
expansion of macro 'QEMU_BUILD_BUG_ON'
QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
^~~~~~~~~~~~~~~~~
migration/postcopy-ram.c:651:5: note: in expansion of macro 'atomic_xchg'
atomic_xchg(&dc->last_begin, now_ms);
^~~~~~~~~~~
/root/src/github.com/philmd/qemu/include/qemu/compiler.h:86:30: error:
static assertion failed: "not expecting:
sizeof(*&dc->page_fault_vcpu_time[cpu]) > ATOMIC_REG_SIZE"
#define QEMU_BUILD_BUG_ON(x) _Static_assert(!(x), "not expecting: " #x)
^
/root/src/github.com/philmd/qemu/include/qemu/atomic.h:183:5: note: in
expansion of macro 'QEMU_BUILD_BUG_ON'
QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
^~~~~~~~~~~~~~~~~
migration/postcopy-ram.c:652:5: note: in expansion of macro 'atomic_xchg'
atomic_xchg(&dc->page_fault_vcpu_time[cpu], now_ms);
^~~~~~~~~~~
/root/src/github.com/philmd/qemu/include/qemu/compiler.h:86:30: error:
static assertion failed: "not expecting:
sizeof(*&dc->page_fault_vcpu_time[cpu]) > ATOMIC_REG_SIZE"
#define QEMU_BUILD_BUG_ON(x) _Static_assert(!(x), "not expecting: " #x)
^
/root/src/github.com/philmd/qemu/include/qemu/atomic.h:183:5: note: in
expansion of macro 'QEMU_BUILD_BUG_ON'
QEMU_BUILD_BUG_ON(sizeof(*ptr) > ATOMIC_REG_SIZE); \
^~~~~~~~~~~~~~~~~
migration/postcopy-ram.c:661:9: note: in expansion of macro 'atomic_xchg'
atomic_xchg(&dc->page_fault_vcpu_time[cpu], 0);
^~~~~~~~~~~
/root/src/github.com/philmd/qemu/rules.mak:66: recipe for target
'migration/postcopy-ram.o' failed
make: *** [migration/postcopy-ram.o] Error 1
make: *** Waiting for unfinished jobs....
On 01/19/2018 07:27 PM, Philippe Mathieu-Daudé wrote: > On 01/15/2018 01:14 PM, Peter Maydell wrote: >> On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: >>> Hi >>> - rebase on top of lastest >>> - fix compilation on 32bit machines >>> - add Peter Xu cleanups >>> >>> Please, apply. >>> >>> The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93: >>> >>> Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000) >>> >>> are available in the Git repository at: >>> >>> git://github.com/juanquintela/qemu.git tags/migration/20180115 >>> >>> for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f: >>> >>> migration: remove notify in fd_error (2018-01-15 12:48:13 +0100) >>> >>> ---------------------------------------------------------------- >>> migration/next for 20180115 >> Applied, thanks. > We have armel/armhf/powerpc hosts failing since this pull due to commit > 3be98be4e9f. > > Those target are currently tested on Shippable CI, eventually adding an > IRC bot we could notice. > > I know companies using QEMU system in embedded armel/armhf hosts, I > don't know about the ppc32 hosts. > This is however unlikely the migration features are used there. > > If 64bit atomic op are required for migration (performance/security) but > not on 32bit system, one way to fix it could be to have the migration > code being optional... so we can disable it on 32bit hosts. > > Regards, > > Phil. > Thank you Phil for report, I have a release this week and it's not yet over. As I remember, I tested build in QEMU's docker build system, but now I checked it on i386 Ubuntu, and yes linker says about unresolved atomic symbols. Next week, I'll have a time to investigate it deeper. -- Best regards, Alexey Perevalov
On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote: > As I remember, I tested build in QEMU's docker build system, > but now I checked it on i386 Ubuntu, and yes linker says about unresolved > atomic symbols. Next week, I'll have a time to investigate it deeper. This sounds like exactly the problem I pointed out in a previous round of this patchset :-( https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html Ignoring comments and sending patches anyway makes me grumpy, especially when the result is exactly "fails obscurely on some architectures only"... thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> wrote: > On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote: >> As I remember, I tested build in QEMU's docker build system, >> but now I checked it on i386 Ubuntu, and yes linker says about unresolved >> atomic symbols. Next week, I'll have a time to investigate it deeper. > > This sounds like exactly the problem I pointed out in a previous > round of this patchset :-( > > https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html > > Ignoring comments and sending patches anyway makes me grumpy, > especially when the result is exactly "fails obscurely on > some architectures only"... It compiles for me. F25 i686 gcc. I did change it to use intptr_t instead of uint64_t. So, I don't know what is going on here. Then, I have a report that clang -m32 didn't work (Mat). I haven't been able yet to reproduce. I don't have 32bits libraries installed on my x86_64 systems. clang compiles for me on both 64 bits (f27) and 32bits native (f25, it is a long history that it is not f27). So, I can agree that we have to fix anything that don't work, but I can't agree that I didn't care about comments, at least I tried to fix the problems you pointed me to. What I don't have is an easier way of compiling on arm and ppc32, but I will search a way to do that for my pull requsets. Sorry about the inconveniences. Later, Juan.
Hi Juan, On 01/20/2018 08:36 PM, Juan Quintela wrote: > Peter Maydell <peter.maydell@linaro.org> wrote: >> On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote: >>> As I remember, I tested build in QEMU's docker build system, >>> but now I checked it on i386 Ubuntu, and yes linker says about unresolved >>> atomic symbols. Next week, I'll have a time to investigate it deeper. >> >> This sounds like exactly the problem I pointed out in a previous >> round of this patchset :-( >> >> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html >> >> Ignoring comments and sending patches anyway makes me grumpy, >> especially when the result is exactly "fails obscurely on >> some architectures only"... > > It compiles for me. F25 i686 gcc. I did change it to use intptr_t > instead of uint64_t. So, I don't know what is going on here. > > Then, I have a report that clang -m32 didn't work (Mat). I haven't been > able yet to reproduce. I don't have 32bits libraries installed on my > x86_64 systems. clang compiles for me on both 64 bits (f27) and 32bits > native (f25, it is a long history that it is not f27). > > So, I can agree that we have to fix anything that don't work, but I > can't agree that I didn't care about comments, at least I tried to fix > the problems you pointed me to. > > What I don't have is an easier way of compiling on arm and ppc32, but I > will search a way to do that for my pull requsets. You can use docker to cross compile (supposed to work on any Linux): $ make docker-test-build@debian-powerpc-cross If you don't want to rebuild all the images the following commands are faster to modify the codebase and rebuild more frequently: $ mkdir -p build_ppc32 $ docker run --rm -it -v `pwd`:`pwd` -w `pwd`/build_ppc32 -u `id -u` qemu:debian-powerpc-cross sh -c '../configure $QEMU_CONFIGURE_OPTS' [...] $ docker run --rm -it -v `pwd`:`pwd` -w `pwd`/build_ppc32 -u `id -u` qemu:debian-powerpc-cross make -j4 subdir-ppc-softmmu [...] CC ppc-softmmu/gdbstub-xml.o CC ppc-softmmu/trace/generated-helpers.o LINK ppc-softmmu/qemu-system-ppc ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_end': /source/qemu/migration/postcopy-ram.c:717: undefined reference to `__atomic_fetch_add_8' /source/qemu/migration/postcopy-ram.c:738: undefined reference to `__atomic_fetch_add_8' ../migration/postcopy-ram.o: In function `mark_postcopy_blocktime_begin': /source/qemu/migration/postcopy-ram.c:651: undefined reference to `__atomic_exchange_8' /source/qemu/migration/postcopy-ram.c:652: undefined reference to `__atomic_exchange_8' /source/qemu/migration/postcopy-ram.c:661: undefined reference to `__atomic_exchange_8' collect2: error: ld returned 1 exit status Makefile:193: recipe for target 'qemu-system-ppc' failed make[1]: *** [qemu-system-ppc] Error 1 Makefile:391: recipe for target 'subdir-ppc-softmmu' failed make: *** [subdir-ppc-softmmu] Error 2
On 20 January 2018 at 23:36, Juan Quintela <quintela@redhat.com> wrote: > Peter Maydell <peter.maydell@linaro.org> wrote: >> On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote: >>> As I remember, I tested build in QEMU's docker build system, >>> but now I checked it on i386 Ubuntu, and yes linker says about unresolved >>> atomic symbols. Next week, I'll have a time to investigate it deeper. >> >> This sounds like exactly the problem I pointed out in a previous >> round of this patchset :-( >> >> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html >> >> Ignoring comments and sending patches anyway makes me grumpy, >> especially when the result is exactly "fails obscurely on >> some architectures only"... > > It compiles for me. F25 i686 gcc. I did change it to use intptr_t > instead of uint64_t. So, I don't know what is going on here. Did you change it to not use the 'nocheck' versions of the macros? The code in master uses 'nocheck' which has exactly the effect of masking this bug on i686... > So, I can agree that we have to fix anything that don't work, but I > can't agree that I didn't care about comments, at least I tried to fix > the problems you pointed me to. I said the could should probably not use the nocheck macros. The code in master is still using those macros, wrongly, which is why this problem shows only on ppc32 and not all 32-bit hosts. thanks -- PMM
On 01/22/2018 01:03 PM, Peter Maydell wrote:
> On 20 January 2018 at 23:36, Juan Quintela <quintela@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote:
>>>> As I remember, I tested build in QEMU's docker build system,
>>>> but now I checked it on i386 Ubuntu, and yes linker says about unresolved
>>>> atomic symbols. Next week, I'll have a time to investigate it deeper.
>>> This sounds like exactly the problem I pointed out in a previous
>>> round of this patchset :-(
>>>
>>> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html
>>>
>>> Ignoring comments and sending patches anyway makes me grumpy,
>>> especially when the result is exactly "fails obscurely on
>>> some architectures only"...
>> It compiles for me. F25 i686 gcc. I did change it to use intptr_t
>> instead of uint64_t. So, I don't know what is going on here.
> Did you change it to not use the 'nocheck' versions of the macros?
> The code in master uses 'nocheck' which has exactly the effect
> of masking this bug on i686...
>
>> So, I can agree that we have to fix anything that don't work, but I
>> can't agree that I didn't care about comments, at least I tried to fix
>> the problems you pointed me to.
> I said the could should probably not use the nocheck macros. The
> code in master is still using those macros, wrongly, which is why
> this problem shows only on ppc32 and not all 32-bit hosts.
clang doesn't have atomic_*_8 function set on 32 platform,
but gcc has.
I also checked on ubuntu server 12.04, looks like no "ATOMIC_RELAXED" in
both gcc and clang toolchain, so
following code
atomic_xchg__nocheck(&a64, b64);
is expanding to
(({ asm volatile("" ::: "memory"); (void)0; }),
__sync_lock_test_and_set(&a64, b64));
and we don't have problem neither in gcc nor in clang. Maybe it's not so
effective
from performance point of view.
I like glib approach.
#if defined(__ATOMIC_SEQ_CST) && !defined(__clang__)
there __ATOMIC_SEQ_CST instead of __ATOMIC_RELAXED in QEMU, but it
doesn't matter.
But clang has atomic_*_[1, 2, 4] functions, so it's not reasonable to
avoid using clang
for all cases.
I want to keep 64bit atomic operations in migration.
Maybe add into atomic.h additional check for clang and 64bit pointer and
in this case use
(({ asm volatile("" ::: "memory"); (void)0; }),
__sync_lock_test_and_set(&a64, b64));
?
>
> thanks
> -- PMM
>
>
>
--
Best regards,
Alexey Perevalov
On 22 January 2018 at 16:25, Alexey Perevalov <a.perevalov@samsung.com> wrote: > I want to keep 64bit atomic operations in migration. Sorry, you can't -- some 32 bit CPUs simply do not provide these operations. You need to rework your design to not require this. thanks -- PMM
On 01/22/2018 07:26 PM, Peter Maydell wrote: > On 22 January 2018 at 16:25, Alexey Perevalov <a.perevalov@samsung.com> wrote: >> I want to keep 64bit atomic operations in migration. > Sorry, you can't -- some 32 bit CPUs simply do not provide these > operations. You need to rework your design to not require this. I would like to ask David, how do you think is it normal to use just one half of now_ms (int64_t), one half of 64 bit value should represent 1200 hours and probably it's enough to keep time difference. > > thanks > -- PMM > > > -- Best regards, Alexey Perevalov
* Alexey Perevalov (a.perevalov@samsung.com) wrote: > On 01/22/2018 07:26 PM, Peter Maydell wrote: > > On 22 January 2018 at 16:25, Alexey Perevalov <a.perevalov@samsung.com> wrote: > > > I want to keep 64bit atomic operations in migration. > > Sorry, you can't -- some 32 bit CPUs simply do not provide these > > operations. You need to rework your design to not require this. > I would like to ask David, > how do you think is it normal to use just one half of now_ms (int64_t), one > half > of 64 bit value should represent 1200 hours and probably it's enough to keep > time > difference. Yes you could use an offset (start of migration?) - if the postcopy phase is taking more than that long we're probably in trouble. But remember your '0' value is special. Dave > > > > thanks > > -- PMM > > > > > > > > -- > Best regards, > Alexey Perevalov -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Juan Quintela <quintela@redhat.com> writes: > Peter Maydell <peter.maydell@linaro.org> wrote: >> On 19 January 2018 at 16:43, Alexey Perevalov <a.perevalov@samsung.com> wrote: >>> As I remember, I tested build in QEMU's docker build system, >>> but now I checked it on i386 Ubuntu, and yes linker says about unresolved >>> atomic symbols. Next week, I'll have a time to investigate it deeper. >> >> This sounds like exactly the problem I pointed out in a previous >> round of this patchset :-( >> >> https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02103.html >> >> Ignoring comments and sending patches anyway makes me grumpy, >> especially when the result is exactly "fails obscurely on >> some architectures only"... > > It compiles for me. F25 i686 gcc. I did change it to use intptr_t > instead of uint64_t. So, I don't know what is going on here. > > Then, I have a report that clang -m32 didn't work (Mat). I haven't been > able yet to reproduce. I don't have 32bits libraries installed on my > x86_64 systems. clang compiles for me on both 64 bits (f27) and 32bits > native (f25, it is a long history that it is not f27). > > So, I can agree that we have to fix anything that don't work, but I > can't agree that I didn't care about comments, at least I tried to fix > the problems you pointed me to. > > What I don't have is an easier way of compiling on arm and ppc32, but I > will search a way to do that for my pull requsets. make docker-test-build@debian-armhf-cross make docker-test-build@debian-powerpc-cross Assuming you have docker setup and working. > > Sorry about the inconveniences. > > Later, Juan. -- Alex Bennée
On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: > Hi > - rebase on top of lastest > - fix compilation on 32bit machines > - add Peter Xu cleanups > > Please, apply. > > The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93: > > Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000) > > are available in the Git repository at: > > git://github.com/juanquintela/qemu.git tags/migration/20180115 > > for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f: > > migration: remove notify in fd_error (2018-01-15 12:48:13 +0100) > > ---------------------------------------------------------------- > migration/next for 20180115 > > ---------------------------------------------------------------- > Alexey Perevalov (6): > migration: introduce postcopy-blocktime capability > migration: add postcopy blocktime ctx into MigrationIncomingState > migration: calculate vCPU blocktime on dst side > migration: postcopy_blocktime documentation > migration: add blocktime calculation into migration-test > migration: add postcopy total blocktime into query-migrate I suggest that we should for the moment revert 3be98be4e9f5 migration: calculate vCPU blocktime on dst side 5f32dc8ee073 migration: add blocktime calculation into migration-test ca6011c23291 migration: add postcopy total blocktime into query-migrate unless there is an imminent fix for the ppc32 issues (which seems unlikely since the code is fundamentally assuming it can atomically do operations which can't be done atomically on all hosts). I haven't yet tested that combination of reverts, I'm guessing at which subsequent commits depend on 3be98be4e9f5. Let me know if you have suggestions for additions/removals from the revert list. thanks -- PMM
* Peter Maydell (peter.maydell@linaro.org) wrote: > On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: > > Hi > > - rebase on top of lastest > > - fix compilation on 32bit machines > > - add Peter Xu cleanups > > > > Please, apply. > > > > The following changes since commit fd06527b80c88c8dde1b35fdc692685b68d2fd93: > > > > Merge remote-tracking branch 'remotes/thibault/tags/samuel-thibault' into staging (2018-01-15 10:39:29 +0000) > > > > are available in the Git repository at: > > > > git://github.com/juanquintela/qemu.git tags/migration/20180115 > > > > for you to fetch changes up to 816306826a45f4d15352e32d157172af3a35899f: > > > > migration: remove notify in fd_error (2018-01-15 12:48:13 +0100) > > > > ---------------------------------------------------------------- > > migration/next for 20180115 > > > > ---------------------------------------------------------------- > > Alexey Perevalov (6): > > migration: introduce postcopy-blocktime capability > > migration: add postcopy blocktime ctx into MigrationIncomingState > > migration: calculate vCPU blocktime on dst side > > migration: postcopy_blocktime documentation > > migration: add blocktime calculation into migration-test > > migration: add postcopy total blocktime into query-migrate > > I suggest that we should for the moment revert > 3be98be4e9f5 migration: calculate vCPU blocktime on dst side > 5f32dc8ee073 migration: add blocktime calculation into migration-test > ca6011c23291 migration: add postcopy total blocktime into query-migrate > > unless there is an imminent fix for the ppc32 issues (which seems > unlikely since the code is fundamentally assuming it can atomically > do operations which can't be done atomically on all hosts). > > I haven't yet tested that combination of reverts, I'm guessing > at which subsequent commits depend on 3be98be4e9f5. Let me know > if you have suggestions for additions/removals from the revert list. It's probably better to remove the whole set of 6, then we can come back to it later rather than leaving something half-implemented in there. Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 22 January 2018 at 12:38, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: > * Peter Maydell (peter.maydell@linaro.org) wrote: >> On 15 January 2018 at 11:52, Juan Quintela <quintela@redhat.com> wrote: >> > Alexey Perevalov (6): >> > migration: introduce postcopy-blocktime capability >> > migration: add postcopy blocktime ctx into MigrationIncomingState >> > migration: calculate vCPU blocktime on dst side >> > migration: postcopy_blocktime documentation >> > migration: add blocktime calculation into migration-test >> > migration: add postcopy total blocktime into query-migrate >> >> I suggest that we should for the moment revert >> 3be98be4e9f5 migration: calculate vCPU blocktime on dst side >> 5f32dc8ee073 migration: add blocktime calculation into migration-test >> ca6011c23291 migration: add postcopy total blocktime into query-migrate >> >> unless there is an imminent fix for the ppc32 issues (which seems >> unlikely since the code is fundamentally assuming it can atomically >> do operations which can't be done atomically on all hosts). >> >> I haven't yet tested that combination of reverts, I'm guessing >> at which subsequent commits depend on 3be98be4e9f5. Let me know >> if you have suggestions for additions/removals from the revert list. > > It's probably better to remove the whole set of 6, then we can come > back to it later rather than leaving something half-implemented in > there. OK. I'm currently running a commit with git revert --no-commit 31bf06a9d6844d^..ca6011c232912 through my build tests, though I'll hold off on actually pushing it for a bit to give people time to comment. thanks -- PMM
On 22 January 2018 at 13:38, Peter Maydell <peter.maydell@linaro.org> wrote: > On 22 January 2018 at 12:38, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote: >> It's probably better to remove the whole set of 6, then we can come >> back to it later rather than leaving something half-implemented in >> there. > > OK. I'm currently running a commit with > git revert --no-commit 31bf06a9d6844d^..ca6011c232912 > through my build tests, though I'll hold off on actually pushing it > for a bit to give people time to comment. I've now pushed this revert to master. thanks -- PMM
© 2016 - 2024 Red Hat, Inc.