On Mon, Sep 21, 2015 at 08:09:48AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabk...@redhat.com> writes:
>
> > On Fri, Sep 18, 2015 at 02:00:38PM +0200, Markus Armbruster wrote:
> >> Several devices don't survive object_unref(object_new(T)): they crash
> >> or hang during cleanup, or they leave dangling pointers behind.
> >>
> >> This breaks at least device-list-properties, because
> >> qmp_device_list_properties() needs to create a device to find its
> >> properties. Broken in commit f4eb32b "qmp: show QOM properties in
> >> device-list-properties", v2.1. Example reproducer:
> >>
> >> $ qemu-system-aarch64 -nodefaults -display none -machine none -S -qmp
> >> stdio
> >> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
> >> "package": ""}, "capabilities": []}}
> >> { "execute": "qmp_capabilities" }
> >> {"return": {}}
> >> { "execute": "device-list-properties", "arguments": { "typename":
> >> "pxa2xx-pcmcia" } }
> >> qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307:
> >> memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void
> >> *)0))' failed.
> >> Aborted (core dumped)
> >> [Exit 134 (SIGABRT)]
> >>
> >> Unfortunately, I can't fix the problems in these devices right now.
> >> Instead, add DeviceClass member cannot_even_create_with_object_new_yet
> >> to mark them:
> >>
> >> * Crash or hang during cleanup (didn't debug them, so I can't say
> >> why): "pxa2xx-pcmcia", "realview_pci", "versatile_pci",
> >> "s390-sclp-event-facility", "sclp"
> >>
> >> * Dangling pointers: all CPUs, plus "allwinner-a10", "digic",
> >> "fsl,imx25", "fsl,imx31", "xlnx,zynqmp", because they create CPUs
> >
> > That's isn't true for all CPU classes, only the ones that (incorrectly)
> > call cpu_exec_init() on instance_init instead of realize. I believe at
> > least TYPE_POWERPC_CPU is safe already.
>
> Okay, I'll try to mark only the ones that actually screw up.
Most of them screw up, today. If you prefer to simply set it to true on
TYPE_CPU and then explicitly override it to false only on the few
subclasses that are already fixed, I think it would be OK.
--
Eduardo
