[qemu-s390x] qemu-iotest 55 broken

[Farhan Ali]

Hi,

I noticed qemu iotest 55 was broken on the latest master (My head commit 
is dbbc277 Merge remote-tracking branch 
'remotes/stefanha/tags/block-pull-request' into staging).

The backtrace of the qemu process when the test fails:

#0  0x00007f82047cd428 in __GI_raise (address@hidden) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f82047cf02a in __GI_abort () at abort.c:89
#2  0x00007f82047c5bd7 in __assert_fail_base (fmt=<optimized out>, 
address@hidden "current_migration", 
address@hidden "migration/migration.c", 
address@hidden,
    address@hidden <__PRETTY_FUNCTION__.30526> 
"migrate_get_current") at assert.c:92
#3  0x00007f82047c5c82 in __GI___assert_fail (assertion=0x55b6f83f91e4 
"current_migration", file=0x55b6f83f9197 "migration/migration.c", 
line=187, function=0x55b6f83fa420 <__PRETTY_FUNCTION__.30526> 
"migrate_get_current") at assert.c:101
#4  0x000055b6f8068c93 in migrate_get_current () at 
migration/migration.c:187
#5  0x000055b6f806c16e in migrate_add_blocker (reason=0x55b6f91797e0, 
errp=0x7ffe73ee6d20) at migration/migration.c:1715
#6  0x000055b6f810caf9 in vmdk_open (bs=0x55b6f91835e0, 
options=0x55b6f91888b0, flags=139266, errp=0x7ffe73ee6d90) at 
block/vmdk.c:1019
#7  0x000055b6f80f55d1 in bdrv_open_driver (bs=0x55b6f91835e0, 
drv=0x55b6f8bba300 <bdrv_vmdk>, node_name=0x0, options=0x55b6f91888b0, 
open_flags=139266, errp=0x7ffe73ee6ea0) at block.c:1272
#8  0x000055b6f80f5f89 in bdrv_open_common (bs=0x55b6f91835e0, 
file=0x55b6f9179490, options=0x55b6f91888b0, errp=0x7ffe73ee6ea0) at 
block.c:1530
#9  0x000055b6f80f8fb6 in bdrv_open_inherit (filename=0x55b6f9182270 
"/home/alifm/kvmdev/qemu/tests/qemu-iotests/scratch/blockdev-target.img", 
reference=0x0, options=0x55b6f91888b0, flags=8194, parent=0x0, 
child_role=0x0,
    errp=0x7ffe73ee7298) at block.c:2889
#10 0x000055b6f80f94ef in bdrv_open (filename=0x55b6f9182270 
"/home/alifm/kvmdev/qemu/tests/qemu-iotests/scratch/blockdev-target.img", 
reference=0x0, options=0x55b6f91713a0, flags=0, errp=0x7ffe73ee7298) at 
block.c:2982
#11 0x000055b6f815baf0 in blk_new_open (filename=0x55b6f9182270 
"/home/alifm/kvmdev/qemu/tests/qemu-iotests/scratch/blockdev-target.img", 
reference=0x0, options=0x55b6f91713a0, flags=0, errp=0x7ffe73ee7298) at 
block/block-backend.c:377
#12 0x000055b6f7e6939d in blockdev_init (file=0x55b6f9182270 
"/home/alifm/kvmdev/qemu/tests/qemu-iotests/scratch/blockdev-target.img", 
bs_opts=0x55b6f91713a0, errp=0x7ffe73ee7298) at blockdev.c:602
#13 0x000055b6f7e6a2de in drive_new (all_opts=0x55b6f90ba630, 
block_default_type=IF_IDE, errp=0x55b6f8c21fd0 <error_fatal>) at 
blockdev.c:994
#14 0x000055b6f7e7b2f2 in drive_init_func (opaque=0x55b6f90f2628, 
opts=0x55b6f90ba630, errp=0x55b6f8c21fd0 <error_fatal>) at vl.c:1162
#15 0x000055b6f823e17b in qemu_opts_foreach (list=0x55b6f8a8b720 
<qemu_drive_opts>, func=0x55b6f7e7b2be <drive_init_func>, 
opaque=0x55b6f90f2628, errp=0x55b6f8c21fd0 <error_fatal>) at 
util/qemu-option.c:1171
#16 0x000055b6f7e7b528 in configure_blockdev (bdo_queue=0x7ffe73ee75d0, 
machine_class=0x55b6f90f2580, snapshot=0) at vl.c:1229
#17 0x000055b6f7e83323 in main (argc=20, argv=0x7ffe73ee76e8, 
envp=0x7ffe73ee7790) at vl.c:4284


Git bisect points to:

commit cda4aa9a5a08777cf13e164c0543bd4888b8adce
Author: Markus Armbruster <address@hidden>
Date:   Fri Mar 8 14:14:40 2019 +0100

    vl: Create block backends before setting machine properties

    qemu-system-FOO's main() acts on command line arguments in its own
    idiosyncratic order.  There's not much method to its madness.
    Whenever we find a case where one kind of command line argument needs
    to refer to something created for another kind later, we rejigger the
    order.

    Block devices get created long after machine properties get processed.
    Therefore, block device machine properties can be created, but not
    set.  No such properties exist.  But the next commit will create some.
    Time to rejigger again: create block devices earlier.

    Signed-off-by: Markus Armbruster <address@hidden>
    Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
    Message-Id: <address@hidden>
    Reviewed-by: Michael S. Tsirkin <address@hidden>

:100644 100644 c22ca447fa480673e9ecfbddad5e8b2965c4d3c4 
e9239d55ad6afc431c16cb9602e167c6ac95b9a1 M	vl.c

It seems the reason is now we are configuring block devices earlier than 
we setting up the migration state, and this breaks for vmdk block devices.

Thanks
Farhan