Re: [RFC PATCH 5/5] hw/ppc/e500: Pass array of CPUs as array of canonical QOM paths

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 31/10/23 22:16, Daniel Henrique Barboza wrote:
> On 10/30/23 11:39, Philippe Mathieu-Daudé wrote:
>> Devices should avoid calling qemu_get_cpu() because this call
>> doesn't work as expected with heterogeneous machines. Such
>> devices often iterate over a cluster of CPUs, which the device's
>> parent has direct access (when creating the child device).
>>
>> We can pass QOM as 'link' between objects, but we can't pass an
>> array of links. Here we exploits QAPI simplicity, by using
>> DEFINE_PROP_ARRAY and a list of strings, each string being the
>> CPU canonical path in QOM tree (which is constant and unique).
>> When the device realizes itself, the original CPU pointer is
>> recovered via a object_resolve_path() call.
>>
>> Inspired-by: Peter Maydell <peter.maydell@linaro.org>
>> Inspired-by: Markus Armbruster <armbru@redhat.com>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> ---
>> Tested with:
>> $ make check-qtest-ppc{,64}
>> $ make check-avocado AVOCADO_TAGS='machine:ppce500 machine:mpc8544ds'
>>
>> RFC: See cover
>>
>> FIXME: Should we free spin_cpu_list using g_autoptr(QList)?
> 
> By looking at how object_property_set_qobject() works I *think* we can 
> free it.
> Perhaps try using g_autofree and see if something explodes, hehe

In another thread, Peter noticed we then call qdev_prop_set_array(),
which takes the ownership, so no need to use g_autoptr in this
particular case (else we trigger a double-free):
https://lore.kernel.org/qemu-devel/CAFEAcA_GC8ypM2Y94KCU9Q_dntF6Na+igu-+0JZJ+MvPFE_HcA@mail.gmail.com/


> Thanks,
> 
> Daniel
> 
>> ---
>>   hw/ppc/e500.c         |  6 ++++++
>>   hw/ppc/ppce500_spin.c | 48 ++++++++++++++++++++++++++++++++++++-------
>>   2 files changed, 47 insertions(+), 7 deletions(-)