Description of problem: qemu-kvm gets coredump if guest is attached with -object and the name of id is set to “mach-virt.ram” but no “memory-backend=mach-virt.ram” is set to “-machine” coincidentally Version-Release number of selected component (if applicable): qemu-kvm-8.0.0-3.el9.aarch64 - 9.3.0 or qemu-kvm-7.2.0-14.el9_2.aarch64 - 9.2.0 How reproducible: 3/3 Steps to Reproduce: 1.boot up with the following cmdline /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 Actual results: 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') Aborted (core dumped) Expected results: No core dumped Additional info: If using /usr/libexec/qemu-kvm -machine virt-rhel9.2.0,memory-backend=mach-virt.ram -object '{"qom-type":"memory-backend-ram","id":"mach-virt.ram","size":4294967296}' -monitor stdio -cpu host Actual results, The guest works well.
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