Hi Jens, the unplug failover stuff is triggering an assertion occasionally on aarch64; but a) I'm not sure the right way to fix it b) And I'm out for a little over a week
so... * no-re...@patchew.org (no-re...@patchew.org) wrote: > Patchew URL: > https://patchew.org/QEMU/20191108104307.125020-1-dgilb...@redhat.com/ > > > > Hi, > > This series failed the docker-quick@centos7 build test. Please find the > testing commands and > their output below. If you have Docker installed, you can probably reproduce > it > locally. > > === TEST SCRIPT BEGIN === > #!/bin/bash > make docker-image-centos7 V=1 NETWORK=1 > time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1 > === TEST SCRIPT END === > > TEST check-unit: tests/test-bdrv-drain > wait_for_migration_fail: unexpected status status=wait-unplug allow_active=1 In tests/migration-test.c we've got wait_for_migration_fail, and it's expecting the state to be any one of: setup, failed or maybe active but it's getting surprised by seeing a 'wait-unplug' So the question is should we see a wait-unplug? the migration code has: if (qemu_savevm_nr_failover_devices()) { migrate_set_state(&s->state, MIGRATION_STATUS_SETUP, MIGRATION_STATUS_WAIT_UNPLUG); Should qemu_savevm_nr_failover_devices() be true? On aarch64 it seems to have a virtio-net device by default and qemu_savevm_nr_failover_devices() checks for devices having dev_unplug_pending but doesn't call it. I see two fixes but am not sure which is right: a) Add 'wait-unplug' to the wait_for_migration_fail (easy) b) Actually call dev_unplug_pending in qemu_savevm_nr_failover_devices so that on a guest which has a virtio-net, but no failover device, the state isn't entered. I think (b) is better, since we shouldn't be exposing the wait-unplug event on setups that don't expect it; but I don't understand the unplug enough to know if this is a safe change. Thoughts? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
