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.mayd...@linaro.org>
Inspired-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <phi...@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_...@mail.gmail.com/
Thanks,
Daniel
---
hw/ppc/e500.c | 6 ++++++
hw/ppc/ppce500_spin.c | 48 ++++++++++++++++++++++++++++++++++++-------
2 files changed, 47 insertions(+), 7 deletions(-)
