I ran into this: $ qemu-system-ppc64 -nodefaults -S -display none -monitor stdio -machine pseries-2.4 QEMU 2.4.50 monitor - type 'help' for more information (qemu) qom-list /machine/unattached/device[5]/dr-connector[255] fdt (struct) entity-sense (uint32) name (string) connector_type (uint32) index (uint32) id (uint32) allocation-state (uint32) indicator-state (uint32) isolation-state (uint32) parent_bus (link<bus>) hotplugged (bool) hotpluggable (bool) realized (bool) type (string) (qemu) qom-list /machine/unattached/device[5]/dr-connector[255]/fdt Device '/machine/unattached/device[5]/dr-connector[255]/fdt' not found
According to the first qom-list, .../fdt exists. According to the second, it doesn't. I messed around in GDB a bit, and found that the second qom-list's final object_resolve_path_component() returns NULL like this: Breakpoint 5, object_resolve_path_component (parent=0x55555659f0f0, part=0x5555564b0660 "fdt") at /home/armbru/work/qemu/qom/object.c:1492 1492 if (prop == NULL) { (gdb) p prop $27 = (ObjectProperty *) 0x55555659faf0 (gdb) n 1496 if (prop->resolve) { (gdb) 1501 } (gdb) p prop->resolve $28 = (ObjectPropertyResolve *) 0x0 The "fdt" property exists, but its ->resolve() callback is null. object_resolve_path_component()'s function comment: * Returns: The final component in the object's canonical path. The canonical * path is the path within the composition tree starting from the root. Doesn't sound like NULL means failure. Its caller object_resolve_abs_path() then also returns NULL. No function comment. Likewise, its caller object_resolve_path_type() returns NULL. Its function comment: * Returns: The matched object or NULL on path lookup failure. Here, NULL definitely means failure, and a specific one: path lookup failure. Its caller qmp_qom_list() then fails, setting a "Device '/machine/unattached/device[5]/dr-connector[255]/fdt' not found" error. Does this work as intended?