From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOQCa-000567-7v for qemu-devel@nongnu.org; Thu, 19 Feb 2015 07:27:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOQCV-0003qj-4O for qemu-devel@nongnu.org; Thu, 19 Feb 2015 07:27:32 -0500 Received: from cantor2.suse.de ([195.135.220.15]:36674 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOQCU-0003qf-SM for qemu-devel@nongnu.org; Thu, 19 Feb 2015 07:27:27 -0500 Message-ID: <54E5D6A4.1050307@suse.de> Date: Thu, 19 Feb 2015 13:27:16 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <87r3tmi3ig.fsf@blackfin.pond.sub.org> In-Reply-To: <87r3tmi3ig.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] bus_unparent() can go into infinite loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: Paolo Bonzini , Bandan Das , "Michael S. Tsirkin" , Alexander Graf , Peter Maydell Am 19.02.2015 um 11:45 schrieb Markus Armbruster: > Reproducer (don't ask): >=20 > $ qemu-system-arm -M virt -S -display none -drive if=3Dscsi,id=3Dfo= o,bus=3D1,file=3Dtmp.qcow2 -device nec-usb-xhci -device usb-storage,drive= =3Dfoo -device virtio-scsi-pci > qemu-system-arm: -drive if=3Dscsi,id=3Dfoo,bus=3D1,file=3Dtmp.qcow2= : Property 'scsi-disk.drive' can't take value 'foo', it's in use > qemu-system-arm: -drive if=3Dscsi,id=3Dfoo,bus=3D1,file=3Dtmp.qcow2= : Setting drive property failed > qemu-system-arm: -device virtio-scsi-pci: Setting drive property fa= iled >=20 > Nevermind the silly error reporting, I got patches to clean that up. I'm actually more confused about the use of PCI devices with the virt machine. Does that now feature Alex' PCI controller by default? Otherwise there would be no bus for those devices. Is this on master or on top of your PCI realize changes or anything? > Stuck in bus_unparent()'s loop: >=20 > while ((kid =3D QTAILQ_FIRST(&bus->children)) !=3D NULL) { > DeviceState *dev =3D kid->child; > object_unparent(OBJECT(dev)); > } Logically speaking, unparenting on QOM level has nothing to with the bus children list. The parent may well be /machine/{unassigned,peripheral{,-anon}} container objects rather than some BusState object, the latter usually has link<> properties only for its qdev-level "children". However I vaguely recall that we shoehorned the unparenting callback to invoke unrealizing the device. What might happen here is that after realizing the device failed, realized =3D=3D false; realized =3D false in= the unparenting path becomes a no-op then. I.e., the realize error handling may need to be reviewed to not just return but to undo any changes such as attaching to some bus (or MemoryRegion, VMState, etc.). Regards, Andreas > (gdb) bt > #0 bus_unparent (obj=3D) > at /home/armbru/work/qemu/hw/core/qdev.c:727 > #1 0x000055555583a165 in object_finalize_child_property (obj=3D,=20 > name=3D, opaque=3D0x555556450060) > at /home/armbru/work/qemu/qom/object.c:1079 > #2 0x000055555583a40c in object_property_del (obj=3D0x55555644ff50,=20 > name=3D0x555556696450 "scsi.1", errp=3D) > at /home/armbru/work/qemu/qom/object.c:800 > #3 0x000055555577f759 in device_unparent (obj=3D0x55555644ff50) > at /home/armbru/work/qemu/hw/core/qdev.c:1230 > #4 0x000055555583a165 in object_finalize_child_property (obj=3D,=20 > name=3D, opaque=3D0x55555644ff50) > at /home/armbru/work/qemu/qom/object.c:1079 > #5 0x000055555583a40c in object_property_del (obj=3D0x55555644f540,=20 > name=3D0x5555566b9620 "virtio-backend", errp=3D) > at /home/armbru/work/qemu/qom/object.c:800 > #6 0x00005555557800c6 in qdev_init (dev=3Ddev@entry=3D0x55555644ff50) > at /home/armbru/work/qemu/hw/core/qdev.c:186 > #7 0x000055555582440e in virtio_scsi_pci_init_pci (vpci_dev=3D0x555556= 44f540) > at /home/armbru/work/qemu/hw/virtio/virtio-pci.c:1157 > #8 0x0000555555825fc8 in virtio_pci_init (pci_dev=3D) > at /home/armbru/work/qemu/hw/virtio/virtio-pci.c:1018 > #9 0x00005555557d6df7 in pci_qdev_init (qdev=3D0x55555644f540) > at /home/armbru/work/qemu/hw/pci/pci.c:1775 > #10 0x000055555577fbc4 in device_realize (dev=3D0x55555644f540,=20 > errp=3D0x7fffffffda60) at /home/armbru/work/qemu/hw/core/qdev.c:247 > #11 0x000055555578125d in device_set_realized (obj=3D0x55555644f540,=20 > value=3D, errp=3D0x7fffffffdb98) > at /home/armbru/work/qemu/hw/core/qdev.c:1040 > #12 0x000055555583927e in property_set_bool (obj=3D0x55555644f540,=20 > v=3D, opaque=3D0x555556698850, name=3D,=20 > errp=3D0x7fffffffdb98) at /home/armbru/work/qemu/qom/object.c:1514 > #13 0x000055555583bc67 in object_property_set_qobject (obj=3D0x55555644= f540,=20 > value=3D, name=3D0x5555559482fd "realized", errp=3D0= x7fffffffdb98) > at /home/armbru/work/qemu/qom/qom-qobject.c:24 > #14 0x000055555583a7b0 in object_property_set_bool ( > obj=3Dobj@entry=3D0x55555644f540, value=3Dvalue@entry=3Dtrue,=20 > name=3Dname@entry=3D0x5555559482fd "realized", errp=3Derrp@entry=3D= 0x7fffffffdb98) > at /home/armbru/work/qemu/qom/object.c:905 > #15 0x000055555570d774 in qdev_device_add (opts=3D0x5555562a38c0) > at /home/armbru/work/qemu/qdev-monitor.c:574 > #16 0x0000555555716c79 in device_init_func (opts=3D,=20 > opaque=3D) at /home/armbru/work/qemu/vl.c:2127 > #17 0x00005555558f48eb in qemu_opts_foreach (list=3D, fu= nc=3D > 0x555555716c70 , opaque=3D0x0,=20 > abort_on_failure=3D) > at /home/armbru/work/qemu/util/qemu-option.c:1057 > #18 0x000055555560e39d in main (argc=3D, argv=3D,=20 > envp=3D) at /home/armbru/work/qemu/vl.c:4244 > (gdb) p dev->parent_obj.class->type->name > $5 =3D 0x55555626c3b0 "scsi-disk" > (gdb) p bus->name > $8 =3D 0x555556696430 "scsi.1" --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)