qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>, Bandan Das <bsd@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] bus_unparent() can go into infinite loop
Date: Thu, 19 Feb 2015 13:27:16 +0100	[thread overview]
Message-ID: <54E5D6A4.1050307@suse.de> (raw)
In-Reply-To: <87r3tmi3ig.fsf@blackfin.pond.sub.org>

Am 19.02.2015 um 11:45 schrieb Markus Armbruster:
> Reproducer (don't ask):
> 
>     $ qemu-system-arm -M virt -S -display none -drive if=scsi,id=foo,bus=1,file=tmp.qcow2 -device nec-usb-xhci -device usb-storage,drive=foo -device virtio-scsi-pci
>     qemu-system-arm: -drive if=scsi,id=foo,bus=1,file=tmp.qcow2: Property 'scsi-disk.drive' can't take value 'foo', it's in use
>     qemu-system-arm: -drive if=scsi,id=foo,bus=1,file=tmp.qcow2: Setting drive property failed
>     qemu-system-arm: -device virtio-scsi-pci: Setting drive property failed
> 
> 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:
> 
>     while ((kid = QTAILQ_FIRST(&bus->children)) != NULL) {
>         DeviceState *dev = 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 == false; realized = 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=<optimized out>)
>     at /home/armbru/work/qemu/hw/core/qdev.c:727
> #1  0x000055555583a165 in object_finalize_child_property (obj=<optimized out>, 
>     name=<optimized out>, opaque=0x555556450060)
>     at /home/armbru/work/qemu/qom/object.c:1079
> #2  0x000055555583a40c in object_property_del (obj=0x55555644ff50, 
>     name=0x555556696450 "scsi.1", errp=<optimized out>)
>     at /home/armbru/work/qemu/qom/object.c:800
> #3  0x000055555577f759 in device_unparent (obj=0x55555644ff50)
>     at /home/armbru/work/qemu/hw/core/qdev.c:1230
> #4  0x000055555583a165 in object_finalize_child_property (obj=<optimized out>, 
>     name=<optimized out>, opaque=0x55555644ff50)
>     at /home/armbru/work/qemu/qom/object.c:1079
> #5  0x000055555583a40c in object_property_del (obj=0x55555644f540, 
>     name=0x5555566b9620 "virtio-backend", errp=<optimized out>)
>     at /home/armbru/work/qemu/qom/object.c:800
> #6  0x00005555557800c6 in qdev_init (dev=dev@entry=0x55555644ff50)
>     at /home/armbru/work/qemu/hw/core/qdev.c:186
> #7  0x000055555582440e in virtio_scsi_pci_init_pci (vpci_dev=0x55555644f540)
>     at /home/armbru/work/qemu/hw/virtio/virtio-pci.c:1157
> #8  0x0000555555825fc8 in virtio_pci_init (pci_dev=<optimized out>)
>     at /home/armbru/work/qemu/hw/virtio/virtio-pci.c:1018
> #9  0x00005555557d6df7 in pci_qdev_init (qdev=0x55555644f540)
>     at /home/armbru/work/qemu/hw/pci/pci.c:1775
> #10 0x000055555577fbc4 in device_realize (dev=0x55555644f540, 
>     errp=0x7fffffffda60) at /home/armbru/work/qemu/hw/core/qdev.c:247
> #11 0x000055555578125d in device_set_realized (obj=0x55555644f540, 
>     value=<optimized out>, errp=0x7fffffffdb98)
>     at /home/armbru/work/qemu/hw/core/qdev.c:1040
> #12 0x000055555583927e in property_set_bool (obj=0x55555644f540, 
>     v=<optimized out>, opaque=0x555556698850, name=<optimized out>, 
>     errp=0x7fffffffdb98) at /home/armbru/work/qemu/qom/object.c:1514
> #13 0x000055555583bc67 in object_property_set_qobject (obj=0x55555644f540, 
>     value=<optimized out>, name=0x5555559482fd "realized", errp=0x7fffffffdb98)
>     at /home/armbru/work/qemu/qom/qom-qobject.c:24
> #14 0x000055555583a7b0 in object_property_set_bool (
>     obj=obj@entry=0x55555644f540, value=value@entry=true, 
>     name=name@entry=0x5555559482fd "realized", errp=errp@entry=0x7fffffffdb98)
>     at /home/armbru/work/qemu/qom/object.c:905
> #15 0x000055555570d774 in qdev_device_add (opts=0x5555562a38c0)
>     at /home/armbru/work/qemu/qdev-monitor.c:574
> #16 0x0000555555716c79 in device_init_func (opts=<optimized out>, 
>     opaque=<optimized out>) at /home/armbru/work/qemu/vl.c:2127
> #17 0x00005555558f48eb in qemu_opts_foreach (list=<optimized out>, func=
>     0x555555716c70 <device_init_func>, opaque=0x0, 
>     abort_on_failure=<optimized out>)
>     at /home/armbru/work/qemu/util/qemu-option.c:1057
> #18 0x000055555560e39d in main (argc=<optimized out>, argv=<optimized out>, 
>     envp=<optimized out>) at /home/armbru/work/qemu/vl.c:4244
> (gdb) p dev->parent_obj.class->type->name
> $5 = 0x55555626c3b0 "scsi-disk"
> (gdb) p bus->name
> $8 = 0x555556696430 "scsi.1"

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)

  reply	other threads:[~2015-02-19 12:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19 10:45 [Qemu-devel] bus_unparent() can go into infinite loop Markus Armbruster
2015-02-19 12:27 ` Andreas Färber [this message]
2015-02-19 13:05   ` Markus Armbruster
2015-02-19 16:04     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E5D6A4.1050307@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=bsd@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).