qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] [PATCH] hw/arm/bcm283x: Fix crash with devic


From: Markus Armbruster
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH] hw/arm/bcm283x: Fix crash with device_add bcm2837 on unsupported machines
Date: Mon, 16 Jul 2018 08:43:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Eduardo Habkost <address@hidden> writes:

> On Thu, Jul 12, 2018 at 10:05:46AM +0200, Paolo Bonzini wrote:
>> On 11/07/2018 22:23, Eduardo Habkost wrote:
>> > On Wed, Jul 11, 2018 at 10:16:42PM +0200, Paolo Bonzini wrote:
>> >> On 11/07/2018 20:30, Eduardo Habkost wrote:
>> >>>> The theoretical behavior should be:
>> >>> It's not clear below where you expect
>> >>>   qdev_set_parent_bus(..., sysbus_get_default())
>> >>> to be called (if it should be called at all).
>> >>>
>> >>> I don't know where it should be called, but I'm absolutely sure
>> >>> instance_init is not the right place.
>> >>
>> >> I think instance_init is fine to call qdev_set_parent_bus on contained
>> >> devices.  Why do you say it's not?
>> > 
>> > Because object_unref(object_new(...)) is not supposed to affect
>> > QEMU global state at all.
>> 
>> It should not affect it.  Any changes to the global state done by
>> instance_init are immediately undone when object_unref destroys the
>> child properties of the object.
>
> I would prefer if it didn't, but not a big deal as long as all
> QOM code is protected by the BQL (it is, right?).
>
> If we get rid of object_new() in qmp_device_list_properties(),
> then most of the restrictions on instance_init can go away,
> anyway.

How could we get rid of object_new()?  As long as we create properties
in code, we need to run the code to find the properties.



reply via email to

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