Re: [PULL 00/30] Migration pull patches (take 4)

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 14 Jan 2020 at 12:53, Juan Quintela <quintela@redhat.com> wrote:
>
> The following changes since commit 3c8a6575985b1652b45bfa670b5e1907d642cfa0:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/usb-20200113-pull-request' into staging (2020-01-13 14:19:57 +0000)
>
> are available in the Git repository at:
>
>   https://github.com/juanquintela/qemu.git tags/migration-pull-pull-request
>
> for you to fetch changes up to b039b02c25d1725cf0296721d98e35e024468b20:
>
>   migration: Support QLIST migration (2020-01-14 13:45:29 +0100)
>
> ----------------------------------------------------------------
> Migration pull request (take 4)
>
> - both patches for x32 archs in
> - reorder the pages to make git bisect happy
>
> Thanks a lot to Daniel for helping with the bugs.  Twice.

tests/qtest/migration-test seems to hang in the aarch32 environment:

peter.m+  3380  0.1  0.0  13484 12848 ?        S    11:10   0:03
                   \_ make -C build/all-a32 check V=1 GCC_COLORS= -j9
peter.m+  5471  0.0  0.0   1460   388 ?        S    11:11   0:00
                       \_ /bin/sh -c
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RAND
peter.m+  5472  0.3  0.0  12984  2228 ?        Sl   11:11   0:09
                       |   \_ tests/qtest/migration-test -m=quick -k
--tap
peter.m+ 17798 99.8  0.9 646064 150512 ?       Sl   11:13  43:04
                       |   |   \_ aarch64-softmmu/qemu-system-aarch64
-qtest unix:
peter.m+ 17814  0.0  0.0      0     0 ?        Z    11:13   0:00
                       |   |   \_ [qemu-system-aar] <defunct>
peter.m+  5473  0.0  0.0   8176  6652 ?        S    11:11   0:00
                       |   \_ perl ./scripts/tap-driver.pl
--test-name=migration-t
peter.m+ 17200  0.0  0.0   1460   404 ?        S    11:13   0:00
                       \_ /bin/sh -c
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RAND
peter.m+ 17201  0.3  0.0  13080  2340 ?        Sl   11:13   0:08
                       |   \_ tests/qtest/migration-test -m=quick -k
--tap
peter.m+ 24275  100  0.8 549340 144160 ?       Sl   11:15  41:32
                       |   |   \_ i386-softmmu/qemu-system-i386 -qtest
unix:/tmp/q
peter.m+ 24308  0.0  0.0      0     0 ?        Z    11:15   0:00
                       |   |   \_ [qemu-system-i38] <defunct>
peter.m+ 17202  0.0  0.0   8172  6772 ?        S    11:13   0:00
                       |   \_ perl ./scripts/tap-driver.pl
--test-name=migration-t
peter.m+ 25399  0.0  0.0   1460   384 ?        S    11:15   0:00
                       \_ /bin/sh -c
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RAND
peter.m+ 25400  0.3  0.0  13092  2280 ?        Sl   11:15   0:08
                           \_ tests/qtest/migration-test -m=quick -k
--tap
peter.m+  2755  100  0.8 557600 145696 ?       Sl   11:17  39:20
                           |   \_ x86_64-softmmu/qemu-system-x86_64
-qtest unix:/t
peter.m+  2763  0.0  0.0      0     0 ?        Z    11:17   0:00
                           |   \_ [qemu-system-x86] <defunct>
peter.m+ 25401  0.0  0.0   8172  6692 ?        S    11:15   0:00
                           \_ perl ./scripts/tap-driver.pl
--test-name=migration-t

(processes started 45 mins ago, unreaped processes in zombie state.)

It looks like the multifd/tcp test fails, but doesn't manage to
actually turn the failure into the test case exiting:

/i386/migration/multifd/tcp: qemu-system-i386: -accel kvm: invalid
accelerator kvm
qemu-system-i386: falling back to tcg
qemu-system-i386: -accel kvm: invalid accelerator kvm
qemu-system-i386: falling back to tcg
qemu-system-i386: multifd_send_sync_main: multifd_send_pages fail
qemu-system-i386: failed to save SaveStateEntry with id(name): 3(ram)
qemu-system-i386: Unable to write to socket: Broken pipe
qemu-system-i386: Unknown combination of migration flags: 0
qemu-system-i386: error while loading state section id 3(ram)
qemu-system-i386: load of migration failed: Invalid argument
[hangs here]

I think you need to find a system which has 32-bit ram_addr_t
and test this, because this is about the fourth time round
for this patchset failing on this configuration.

thanks
-- PMM