qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Daniel P. Berrange <berrange@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org
Subject: Trying to understand QOM object creation and property linking
Date: Wed, 05 Jan 2022 18:03:46 +0000	[thread overview]
Message-ID: <87czl6jb79.fsf@linaro.org> (raw)

Hi,

I'm having a hell of a time trying to create a new SoC+Board model from
scratch. The problem comes down to trying to expose some properties to
the underlying CPU from my board model. So I have:

  static const TypeInfo pipico_machine_types[] = {
      {
          .name           = TYPE_PIPICO_MACHINE,
          .parent         = TYPE_MACHINE,
          .instance_size  = sizeof(PiPicoMachineState),
          .class_size     = sizeof(PiPicoMachineClass),
          .class_init     = pipico_machine_class_init,
      }
  };

and the class init sets:

    MachineClass *mc = MACHINE_CLASS(oc);
    ...
    mc->desc = g_strdup_printf("Raspberry Pi Pico");
    mc->init = pipico_machine_init;
    ...

and finally when I init the machine I do the following:

static void pipico_machine_init(MachineState *machine)
{
    PiPicoMachineState *s = PIPICO_MACHINE(machine);
    ...
    MemoryRegion *system_memory = get_system_memory();

    ...
    
    /* initialize external Flash device */
    memory_region_init_rom(&s->flash, NULL,
                           "pico.flash0", 256 * KiB, &error_fatal);
    memory_region_add_subregion(system_memory, 0, &s->flash);

    /* Setup the SOC */
    object_initialize_child(OBJECT(machine), "soc", &s->soc, TYPE_RP2040);

    /* link properties from machine the SoC needs */
    object_property_set_link(OBJECT(&s->soc), "memory",
                             OBJECT(system_memory), &error_fatal);

    sysbus_realize(SYS_BUS_DEVICE(&s->soc), &error_fatal);


The initialisation of the SoC is simple because I can't do much until
things are realised:

static void rp2040_init(Object *obj)
{
    RP2040State *s = RP2040(obj);
    int n;

    fprintf(stderr, "%s: %p\n", __func__, obj);

    for (n = 0; n < RP2040_NCPUS; n++) {
        object_initialize_child(obj, "cpu[*]", &s->armv7m[n], TYPE_ARMV7M);
        qdev_prop_set_string(DEVICE(&s->armv7m[n]), "cpu-type",
                             ARM_CPU_TYPE_NAME("cortex-m0"));
    }
}


However when I get to realize the SoC itself:

static void rp2040_realize(DeviceState *dev, Error **errp)
{
    RP2040State *s = RP2040(dev);
    Object *obj = OBJECT(dev);
    int n;

    if (!s->board_memory) {
        error_setg(errp, "%s: memory property was not set", __func__);
        return;
    }

    /* initialize internal 16 KB internal ROM */
    memory_region_init_rom(&s->rom, obj, "rp2040.rom0", 16 * KiB, errp);
    memory_region_add_subregion(s->board_memory, 0, &s->rom);

    /* SRAM (Main 256k bank + two 4k banks)*/
    memory_region_init_ram(&s->sram03, obj, "rp2040.sram03", 256 * KiB, errp);
    memory_region_add_subregion(s->board_memory, RP2040_SRAM_BASE, &s->sram03);

    memory_region_init_ram(&s->sram4, obj, "rp2040.sram4", 4 * KiB, errp);
    memory_region_add_subregion(s->board_memory, RP2040_SRAM4_BASE, &s->sram4);

    memory_region_init_ram(&s->sram5, obj, "rp2040.sram5", 4 * KiB, errp);
    memory_region_add_subregion(s->board_memory, RP2040_SRAM5_BASE, &s->sram5);

    ...

    for (n = 0; n < RP2040_NCPUS; n++) {
        /* DeviceState *cpudev = DEVICE(&s->armv7m[i]); */
        Object *cpuobj = OBJECT(&s->armv7m[n]);

        object_property_set_link(cpuobj, "memory",
                                 OBJECT(&s->board_memory), errp);

And this passing of the link down to the CPU I segfault:

  rp2040_init: 0x555556d08710

  Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
  object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
  1999        g_hash_table_iter_init(&iter, obj->parent->properties);
  (gdb) bt
  #0  object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
  #1  0x0000555555fb27ea in object_get_canonical_path (obj=0x555556d0ea28) at ../../qom/object.c:2025
  #2  0x0000555555fb1250 in object_property_set_link (obj=0x555556d087a0, name=0x5555563190a2 "memory", value=0x555556d0ea28, errp=0x7fffffffe0f0) at ../../qom/object.c:1445
  #3  0x0000555555cf3c23 in rp2040_realize (dev=0x555556d08710, errp=0x7fffffffe0f0) at ../../hw/arm/rp2040.c:85
  #4  0x0000555555fa9323 in device_set_realized (obj=0x555556d08710, value=true, errp=0x7fffffffe200) at ../../hw/core/qdev.c:532
  #5  0x0000555555fb300d in property_set_bool (obj=0x555556d08710, v=0x555556dced10, name=0x5555563822b9 "realized", opaque=0x555556a3a6d0, errp=0x7fffffffe200) at ../../qom/object.c:2268
  #6  0x0000555555fb1054 in object_property_set (obj=0x555556d08710, name=0x5555563822b9 "realized", v=0x555556dced10, errp=0x7fffffffe200) at ../../qom/object.c:1403
  #7  0x0000555555fb53ff in object_property_set_qobject (obj=0x555556d08710, name=0x5555563822b9 "realized", value=0x555556e79bc0, errp=0x555556918de0 <error_fatal>) at ../../qom/qom-qobject.c:28
  #8  0x0000555555fb13b9 in object_property_set_bool (obj=0x555556d08710, name=0x5555563822b9 "realized", value=true, errp=0x555556918de0 <error_fatal>) at ../../qom/object.c:1472
  #9  0x0000555555fa8beb in qdev_realize (dev=0x555556d08710, bus=0x555556d0f240, errp=0x555556918de0 <error_fatal>) at ../../hw/core/qdev.c:334
  #10 0x00005555559f0e28 in sysbus_realize (dev=0x555556d08710, errp=0x555556918de0 <error_fatal>) at ../../hw/core/sysbus.c:256
  #11 0x0000555555cf3f0e in pipico_machine_init (machine=0x555556d08600) at ../../hw/arm/raspi_pico.c:74
  #12 0x00005555559ed71b in machine_run_board_init (machine=0x555556d08600) at ../../hw/core/machine.c:1184
  #13 0x0000555555e67f2c in qemu_init_board () at ../../softmmu/vl.c:2655
  #14 0x0000555555e6814a in qmp_x_exit_preconfig (errp=0x555556918de0 <error_fatal>) at ../../softmmu/vl.c:2743
  #15 0x0000555555e6a811 in qemu_init (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/vl.c:3778
  #16 0x0000555555884ebd in main (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/main.c:49

So have I discovered a bug in QOM handling or misunderstood the way
properties are meant to be shared from the main machine to the
underlying CPU?

Follow-up questions, does only creating the main memory aliases as part
of the SoC make sense? My rational is most of the memory is part of the
SoC not the board. I assume later RP2040 based boards may have different
flash configs or even external memory.

The current (messy) state of my tree can be seen at:

  https://gitlab.com/stsquad/qemu/-/commits/arm/picopi-rfc

-- 
Alex Bennée


             reply	other threads:[~2022-01-05 18:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 18:03 Alex Bennée [this message]
2022-01-05 19:03 ` Trying to understand QOM object creation and property linking Philippe Mathieu-Daudé
2022-01-05 21:02   ` Alex Bennée
2022-01-06 11:16     ` Peter Maydell
2022-01-06 14:20       ` Alex Bennée
2022-01-06 15:04         ` Peter Maydell
2022-01-06 15:44           ` Alex Bennée
2022-01-06 15:52             ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czl6jb79.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).