GDB debugging
(gdb) r -machine virt-rhel9.2.0 -object '{"qom-type":"memory-backend-ram","id":"mach-virt.ram","size":4294967296}' -monitor stdio -cpu host
Starting program: /usr/libexec/qemu-kvm -machine virt-rhel9.2.0 -object '{"qom-type":"memory-backend-ram","id":"mach-virt.ram","size":4294967296}' -monitor stdio -cpu host
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0xfffff611a940 (LWP 123245)]
QEMU 7.2.0 monitor - type 'help' for more information
(qemu) Unexpected error in object_property_try_add() at ../qom/object.c:1239:
qemu-kvm: attempt to add duplicate property 'mach-virt.ram' to object (type 'container')

Thread 1 "qemu-kvm" received signal SIGABRT, Aborted.
0x0000fffff70e3640 in __pthread_kill_implementation () from /lib64/libc.so.6
(gdb) bt
#0  0x0000fffff70e3640 in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x0000fffff709e7fc in raise () from /lib64/libc.so.6
#2  0x0000fffff7086030 in abort () from /lib64/libc.so.6
#3  0x0000aaaaab2a6e9c in error_handle_fatal ()
#4  0x0000aaaaab2a6484 in error_setg_internal ()
#5  0x0000aaaaab1709a4 in object_property_try_add ()
#6  0x0000aaaaab171ed8 in object_property_try_add_child ()
#7  0x0000aaaaaad5c05c in machine_run_board_init ()
#8  0x0000aaaaaadd11c0 in qmp_x_exit_preconfig ()
#9  0x0000aaaaaadd4898 in qemu_init ()
#10 0x0000aaaaaad16948 in main ()

The similar issue also can be reproduced on x86 side
[root@dell-per750-18 x86_64]# /usr/libexec/qemu-kvm -machine q35 -object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":4294967296}' -monitor stdio
QEMU 6.2.0 monitor - type 'help' for more information
(qemu) Unexpected error in object_property_try_add() at ../qom/object.c:1224:
qemu-kvm: attempt to add duplicate property 'pc.ram' to object (type 'container')
Aborted (core dumped)

The similar issue also could reproduce on s390x:
[root@l42 home]# /usr/libexec/qemu-kvm -machine s390-ccw-virtio -object '{"qom-type":"memory-backend-ram","id":"s390.ram","size":4294967296}' -monitor stdio -cpu host
QEMU 8.0.0 monitor - type 'help' for more information
(qemu) Unexpected error in object_property_try_add() at ../qom/object.c:1239:
qemu-kvm: attempt to add duplicate property 's390.ram' to object (type 'container')
Aborted (core dumped)


@thuth @

@smitterl FYI

Unclear to me if there is a relationship to Paolo's commit 26f88d84dab62e6eb3ec72737ccb155d06049e3a or perhaps commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9, so I'll start with you Igor under the assumption you know a bit about the code.

It's also unclear whether this can be triggered via libvirt - if not, then although a crash, it becomes more of an upstream-ish type problem.

Here is what I observed, without the `memory-backend` in the `-machine`, qemu will not create the memdev in the `qemu_resolve_machine_memdev()` function. At the same time, qemu will resolve -object '{"qom-type":"memory-backend-ram","id":"mach-virt.ram","size":4294967296}' option, so the id `mach-virt.ram` will be added as child of the object root in the `qemu_create_late_backends` function.

qemu_create_late_backends
  -> object_option_foreach_add
    -> user_creatable_add_qapi
      -> user_creatable_add_type
        -> object_property_try_add_child(object_get_objects_root(), "mach-virt.ram", obj, &err)

So the id "mach-virt.ram" has existed as child in the objects root. Later, in the `machine_run_board_init()` function, qemu didn't create memdev yet, so it will call `create_default_memdev()` with the `machine_class->default_ram_id`, unfortunately, it's value is "mach-virt.ram", so it will cause:

Unexpected error in object_property_try_add() at ../qom/object.c:1239:
qemu-kvm: attempt to add duplicate property 'mach-virt.ram' to object (type 'container')

      if (machine->memdev) {
          ram_addr_t backend_size = object_property_get_uint(OBJECT(machine->memdev),
          ¦       ¦       ¦       ¦       ¦       ¦       ¦  "size",  &error_abort);
          if (backend_size != machine->ram_size) {
          ¦   error_setg(errp, "Machine memory size does not match the size of the memory backend");
          ¦   return;
          }
      } else if (machine_class->default_ram_id && machine->ram_size &&
          ¦      numa_uses_legacy_mem()) {
          if (!create_default_memdev(current_machine, mem_path, errp)) {
          ¦   return;
          }
      }

But if we use the option `-machine virt,memory-backend=mach-virt.ram`, the memdev will be created, so everything is fine.

I'm not sure how should we fix it?

Fix posted upstream:
https://patchwork.kernel.org/project/qemu-devel/patch/20230522131717.3780533-1-imammedo@redhat.com/

Patch has been merged: https://gitlab.com/qemu-project/qemu/-/commit/a37531f2381c4e294e48b1417089474128388b44

Decreasing priority as this is a corner/negative scenario and can be avoided by libvirt.

I don't think is worth backporting.
Lets move it to 9.4 and get the fix with rebase

After testing with latest QEMU, the abort is no longer visible and the error message clearly indicates how to solve the problem.

[1] With qemu-kvm < 8.1.0

[root@dell-per7525-22 ~]# /usr/libexec/qemu-kvm --version
QEMU emulator version 8.0.0 (qemu-kvm-8.0.0-12.el9)

[root@dell-per7525-22 ~]# /usr/libexec/qemu-kvm -machine q35 -object memory-backend-ram,id=pc.ram,size=4294967296
Unexpected error in object_property_try_add() at ../qom/object.c:1239:
qemu-kvm: attempt to add duplicate property 'pc.ram' to object (type 'container')
Aborted (core dumped)

[2] With qemu-kvm-8.1.0-1

[root@dell-per750-24 ~]# /usr/libexec/qemu-kvm --version
QEMU emulator version 8.1.0 (qemu-kvm-8.1.0-1.el9)

[root@dell-per750-24 ~]# /usr/libexec/qemu-kvm -machine q35 -object memory-backend-ram,id=pc.ram,size=4294967296
qemu-kvm: object name 'pc.ram' is reserved for the default RAM backend, it can't be used for any other purposes. Change the object's 'id' to something else

According to comment 15 and TestOnly keyword, moving the bug to VERIFIED