On Mon, Sep 21, 2015 at 08:14:56AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabk...@redhat.com> writes:
>
> > On Fri, Sep 18, 2015 at 08:42:54PM +0200, Thomas Huth wrote:
> >> On 18/09/15 14:00, 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
> >> >
> >> > * Assert kvm_enabled(): "host-x86_64-cpu", host-i386-cpu",
> >> > "host-powerpc64-cpu", "host-embedded-powerpc-cpu",
> >> > "host-powerpc-cpu"
> >>
> >> I just had a look at the powerpc code - you're likely talking about
> >> the "assert(kvm_enabled());" in the kvmppc_host_cpu_initfn() in
> >> target-ppc/kvm.c ? That should be fine, I think, because
> >> kvm_ppc_register_host_cpu_type() is only done on ppc when KVM has been
> >> enabled.
>
> Easy to verify on a KVM-capable PPC host: try -device C,help with KVM on
> and off, where C is the appropriate host CPU.
>
> > It's true that currently the assert() will never trigger, but we will
> > have to eventually move class registration to type_init if we want to
> > make a generic query-cpu-definitions implementation work properly
> > without depending on global machine accel configuration.
>
> Good point. These CPUs need a TODO marker.
>
> > It won't hurt to set cannot_even_create_with_object_new_yet properly to
> > reflect that the class isn't ready yet.
>
> Marking cannot_even_create_with_object_new_yet() is the obvious TODO
> marker. It has an unnecessary side effect: we disable introspection for
> these CPUs needlessly. Tolerable?
To me, it is. We already disable introspection of these CPUs needlessly
in all cases except when KVM is explicitly enabled in the command-line.
--
Eduardo
