qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-stable] [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-pro


From: Thomas Huth
Subject: Re: [Qemu-stable] [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-properties against broken devices
Date: Mon, 21 Sep 2015 17:48:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 21/09/15 08:14, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> 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.

In both cases (KVM on and off), I simply get:

# qemu-system-ppc64 -machine accel=tcg -device host-powerpc64-cpu,help
'host-powerpc64-cpu' is not a valid device model name
# qemu-system-ppc64 -machine accel=kvm -device host-powerpc64-cpu,help
'host-powerpc64-cpu' is not a valid device model name

No crash/abort here.

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]