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

[Philippe Mathieu-Daudé]

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(-)