| Message ID | 1430999444-24315-1-git-send-email-quintela@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 7 May 2015 at 12:50, Juan Quintela <quintela@redhat.com> wrote: > > > Hi again > > For v2 > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit > windows and 32bit windows was not enough) > > - Now, we have versions 2.4 everywhere (thanks Eric) > > - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. > > Please apply, and sorry for the inconvenience. Fails to build on win32: LINK arm-softmmu/qemu-system-arm.exe arch_init.o: In function `do_compress_ram_page': /home/petmay01/linaro/qemu-for-merges/arch_init.c:879: undefined reference to `___sync_fetch_and_add_8' collect2: ld returned 1 exit status It's not valid to try to do atomic operations on a type that's larger than the native pointer type. (This will also cause compile issues on ppc32.) Unfortunately we don't currently have a way to make this a compile failure on normal 32-bit x86 setups... thanks -- PMM
On 05/07/2015 06:45 AM, Peter Maydell wrote: > Fails to build on win32: > > LINK arm-softmmu/qemu-system-arm.exe > arch_init.o: In function `do_compress_ram_page': > /home/petmay01/linaro/qemu-for-merges/arch_init.c:879: undefined > reference to `___sync_fetch_and_add_8' > collect2: ld returned 1 exit status > > It's not valid to try to do atomic operations on a type > that's larger than the native pointer type. (This will also > cause compile issues on ppc32.) Unfortunately we don't > currently have a way to make this a compile failure on > normal 32-bit x86 setups... Right now, patch 8/16 is the culprit: + atomic_inc(&acct_info.norm_pages); which expands to: include/qemu/atomic.h:#define atomic_inc(ptr) ((void) __sync_fetch_and_add(ptr, 1)) I wonder if include/qemu/atomic.h could enhance the #define wrappers to add no-op compile-time checking, something like (untested): #define atomic_add(ptr, n) do { \ QEMU_BUILD_BUG_ON(sizeof(ptr) > sizeof(void*)); \ __sync_fetch_and_add(ptr, 1); \ } while (0)
On 07/05/2015 16:43, Eric Blake wrote: > > I wonder if include/qemu/atomic.h could enhance the #define wrappers to > add no-op compile-time checking, something like (untested): > > #define atomic_add(ptr, n) do { \ > QEMU_BUILD_BUG_ON(sizeof(ptr) > sizeof(void*)); \ > __sync_fetch_and_add(ptr, 1); \ > } while (0) Yes, though it would have to be a statement expression rather than a do...while. Paolo
On (Thu) 07 May 2015 [13:45:26], Peter Maydell wrote: > On 7 May 2015 at 12:50, Juan Quintela <quintela@redhat.com> wrote: > > > > > > Hi again > > > > For v2 > > > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit > > windows and 32bit windows was not enough) > > > > - Now, we have versions 2.4 everywhere (thanks Eric) > > > > - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. > > > > Please apply, and sorry for the inconvenience. > > Fails to build on win32: Does the buildbot try all these combinations? I want to have a 'stage' branch where I just push unapplied patches and receive complaints before sending a pull req. Thanks, Amit
On Thu, May 07, 2015 at 11:40:50PM +0530, Amit Shah wrote: > On (Thu) 07 May 2015 [13:45:26], Peter Maydell wrote: > > On 7 May 2015 at 12:50, Juan Quintela <quintela@redhat.com> wrote: > > > > > > > > > Hi again > > > > > > For v2 > > > > > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit > > > windows and 32bit windows was not enough) > > > > > > - Now, we have versions 2.4 everywhere (thanks Eric) > > > > > > - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. > > > > > > Please apply, and sorry for the inconvenience. > > > > Fails to build on win32: > > Does the buildbot try all these combinations? I want to have a > 'stage' branch where I just push unapplied patches and receive > complaints before sending a pull req. The buildbot is dead and requires maintenance: http://buildbot.b1-systems.de/qemu/one_line_per_build There are two alternatives: 1. Travis (see .travis.yml) but it's missing mingw32. It will never be able to do builds for host operating systems that do not support cross-compilation from Linux. 2. patchew (http://qemu.patchew.org/) but it only has Fedora 20 x86_64 builds at the moment. Adding mingw32 cross-compilation should be possible but it scans the mailing list rather than git repos. The source code to patchew is available here: https://github.com/famz/patchew The trouble with continuous integration and build farms is that they require maintenance. I think patchew is the best bet right now since Fam is developing it. Stefan
On (Fri) 08 May 2015 [10:31:56], Stefan Hajnoczi wrote: > On Thu, May 07, 2015 at 11:40:50PM +0530, Amit Shah wrote: > > On (Thu) 07 May 2015 [13:45:26], Peter Maydell wrote: > > > On 7 May 2015 at 12:50, Juan Quintela <quintela@redhat.com> wrote: > > > > > > > > > > > > Hi again > > > > > > > > For v2 > > > > > > > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit > > > > windows and 32bit windows was not enough) > > > > > > > > - Now, we have versions 2.4 everywhere (thanks Eric) > > > > > > > > - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. > > > > > > > > Please apply, and sorry for the inconvenience. > > > > > > Fails to build on win32: > > > > Does the buildbot try all these combinations? I want to have a > > 'stage' branch where I just push unapplied patches and receive > > complaints before sending a pull req. > > The buildbot is dead and requires maintenance: > http://buildbot.b1-systems.de/qemu/one_line_per_build > > There are two alternatives: > > 1. Travis (see .travis.yml) but it's missing mingw32. It will never be > able to do builds for host operating systems that do not support > cross-compilation from Linux. > > 2. patchew (http://qemu.patchew.org/) but it only has Fedora 20 x86_64 > builds at the moment. Adding mingw32 cross-compilation should be > possible but it scans the mailing list rather than git repos. > > The source code to patchew is available here: > https://github.com/famz/patchew > > The trouble with continuous integration and build farms is that they > require maintenance. I think patchew is the best bet right now since > Fam is developing it. Yes, thanks a lot! I'm wondering how Peter does his builds, and if he can share his recipes or build farms for maintainer trees (or just some -staging tree like the kernel). Amit
On 11 May 2015 at 12:04, Amit Shah <amit.shah@redhat.com> wrote: > I'm wondering how Peter does his builds, and if he can share his > recipes or build farms for maintainer trees (or just some -staging > tree like the kernel). https://git.linaro.org/people/peter.maydell/misc-scripts.git and notably the remake-merge-builds script, which describes the configs I build on my x86-64 box. I also build on OSX and on a 32-bit ARM system. (This is all behind the local firewall and I'm afraid I can't provide access to other people.) The major thing is that buildbots which build for native x86-64 are almost useless, because everybody tests on that anyway. Useful buildbots need to be building for the obscure cases: * OSX * 32-bit systems * ARM, PPC and other non-standard host architectures * clang * Windows * linux-user only and static-only builds Unfortunately this implies maintaining an awkward build farm full of devboards and other fragile hardware. -- PMM
Stefan Hajnoczi <stefanha@redhat.com> writes: > On Thu, May 07, 2015 at 11:40:50PM +0530, Amit Shah wrote: >> On (Thu) 07 May 2015 [13:45:26], Peter Maydell wrote: >> > On 7 May 2015 at 12:50, Juan Quintela <quintela@redhat.com> wrote: >> > > >> > > >> > > Hi again >> > > >> > > For v2 >> > > >> > > - fix 32bit compilation (as said, compiling for 64bit linux, 64bit >> > > windows and 32bit windows was not enough) >> > > >> > > - Now, we have versions 2.4 everywhere (thanks Eric) >> > > >> > > - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. >> > > >> > > Please apply, and sorry for the inconvenience. >> > >> > Fails to build on win32: >> >> Does the buildbot try all these combinations? I want to have a >> 'stage' branch where I just push unapplied patches and receive >> complaints before sending a pull req. > > The buildbot is dead and requires maintenance: > http://buildbot.b1-systems.de/qemu/one_line_per_build > > There are two alternatives: > > 1. Travis (see .travis.yml) but it's missing mingw32. It will never be > able to do builds for host operating systems that do not support > cross-compilation from Linux. In theory you can get some cross compilers on Travis' trusty images. I believe they have some docker based solution that might make it easier to get cross compilation working for various (x86-based) distros. > > 2. patchew (http://qemu.patchew.org/) but it only has Fedora 20 x86_64 > builds at the moment. Adding mingw32 cross-compilation should be > possible but it scans the mailing list rather than git repos. > > The source code to patchew is available here: > https://github.com/famz/patchew > > The trouble with continuous integration and build farms is that they > require maintenance. I think patchew is the best bet right now since > Fam is developing it. We build a few variants but the data is hard to mine. We've been experimenting with kernelci.org to aggregate result for kernel builds from various places internally. One problem would be where the information on failures should be sent? > > Stefan
* Peter Maydell (peter.maydell@linaro.org) wrote: > On 11 May 2015 at 12:04, Amit Shah <amit.shah@redhat.com> wrote: > > I'm wondering how Peter does his builds, and if he can share his > > recipes or build farms for maintainer trees (or just some -staging > > tree like the kernel). > > https://git.linaro.org/people/peter.maydell/misc-scripts.git > and notably the remake-merge-builds script, which describes > the configs I build on my x86-64 box. I also build on OSX and > on a 32-bit ARM system. (This is all behind the local firewall > and I'm afraid I can't provide access to other people.) > > The major thing is that buildbots which build for native x86-64 > are almost useless, because everybody tests on that anyway. > Useful buildbots need to be building for the obscure cases: > * OSX > * 32-bit systems > * ARM, PPC and other non-standard host architectures > * clang > * Windows > * linux-user only and static-only builds > > Unfortunately this implies maintaining an awkward build farm > full of devboards and other fragile hardware. If only we had an emulator..... Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Hi again For v2 - fix 32bit compilation (as said, compiling for 64bit linux, 64bit windows and 32bit windows was not enough) - Now, we have versions 2.4 everywhere (thanks Eric) - Liang Li sent a new patch to the list to fix the update of a migration parameter, included. Please apply, and sorry for the inconvenience. Later, Juan. [v1] This patch series got: - migration compression patches by Liang Li I have to modify ""type" to "struct" in qapi - division by zero fixed by Michael Champan. Thanks, please apply. The following changes since commit 38003aee196a96edccd4d64471beb1b67e9b2b17: Merge remote-tracking branch 'remotes/rth/tags/tcg-next-20150505' into staging (2015-05-06 11:16:35 +0100) are available in the git repository at: git://github.com/juanquintela/qemu.git tags/migration/20150507 for you to fetch changes up to 9a43a8e9560629dd788c311c5cae072333f2e7f4: migration: Fix migration state update issue (2015-05-07 13:41:47 +0200) ---------------------------------------------------------------- migration/next for 20150507 ---------------------------------------------------------------- Liang Li (15): docs: Add a doc about multiple thread compression migration: Add the framework of multi-thread compression migration: Add the framework of multi-thread decompression qemu-file: Add compression functions to QEMUFile arch_init: Alloc and free data struct for compression arch_init: Add and free data struct for decompression migration: Split save_zero_page from ram_save_page migration: Add the core code of multi-thread compression migration: Make compression co-work with xbzrle migration: Add the core code for decompression migration: Add interface to control compression migration: Use an array instead of 3 parameters migration: Add qmp commands to set and query parameters migration: Add hmp interface to set and query parameters migration: Fix migration state update issue Michael Chapman (1): migration: avoid divide by zero in xbzrle cache miss rate arch_init.c | 516 ++++++++++++++++++++++++++++++++++++-- docs/multi-thread-compression.txt | 149 +++++++++++ hmp-commands.hx | 17 ++ hmp.c | 65 +++++ hmp.h | 4 + include/migration/migration.h | 10 + include/migration/qemu-file.h | 3 + migration/migration.c | 122 +++++++++ migration/qemu-file.c | 39 +++ monitor.c | 25 ++ qapi-schema.json | 79 +++++- qmp-commands.hx | 57 +++++ 12 files changed, 1059 insertions(+), 27 deletions(-) create mode 100644 docs/multi-thread-compression.txt