In further discussions and checks Andrew and I found: Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. strlen () at ../sysdeps/aarch64/strlen.S:94 94 ../sysdeps/aarch64/strlen.S: No such file or directory. (gdb) bt #0 strlen () at ../sysdeps/aarch64/strlen.S:94 #1 0x0000aaaaab04fd84 in qmp_query_cpu_model_expansion (type=, model=0xaaaaabcd91b0, errp=errp@entry=0xffffffffee60) at ./target/arm/monitor.c:140 #2 0x0000aaaaab0300a0 in qmp_marshal_query_cpu_model_expansion (args=, ret=0xffffffffef10, errp=0xffffffffef08) at ./b/qemu/qapi/qapi-commands-machine-target.c:183 #3 0x0000aaaaab412ba0 in do_qmp_dispatch (errp=0xffffffffef60, allow_oob=, request=, cmds=0xaaaaabcd92f0) at ./qapi/qmp-dispatch.c:132 #4 qmp_dispatch (cmds=0xaaaaabcd92f0, request=0xffffec006c70, allow_oob=) at ./qapi/qmp-dispatch.c:175 #5 0x0000aaaaab306850 in monitor_qmp_dispatch (mon=0xaaaaabcd91d0, req=) at ./monitor/qmp.c:145 #6 0x0000aaaaab307088 in monitor_qmp_bh_dispatcher (data=) at ./monitor/qmp.c:234 #7 0x0000aaaaab45eb00 in aio_bh_call (bh=0xaaaaabbf32c0) at ./util/async.c:89 #8 aio_bh_poll (ctx=ctx@entry=0xaaaaabbf1e80) at ./util/async.c:117 #9 0x0000aaaaab46243c in aio_dispatch (ctx=0xaaaaabbf1e80) at ./util/aio-posix.c:459 #10 0x0000aaaaab45e9d8 in aio_ctx_dispatch (source=, callback=, user_data=) at ./util/async.c:268 #11 0x0000fffff7d1bc30 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #12 0x0000aaaaab46147c in glib_pollfds_poll () at ./util/main-loop.c:219 #13 os_host_main_loop_wait (timeout=187650001905680) at ./util/main-loop.c:242 #14 main_loop_wait (nonblocking=) at ./util/main-loop.c:518 #15 0x0000aaaaab113330 in main_loop () at ./vl.c:1810 #16 0x0000aaaaaaed4bd0 in main (argc=, argv=, envp=) at ./vl.c:4492 (gdb) Which is a reaction to the probing of caps like: $ nc 127.0.0.1 4444 {"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 4}, "package": "Debian 1:4.2-3ubuntu6.3~cloud0"}, "capabilities": ["oob"]}} { "execute": "qmp_capabilities" } {"return": {}} {"execute":"query-cpu-model-expansion","arguments":{"type":"full","model":{"name":"host"}}} So it is passing a null pointer and breaking. Not 100% that this "is it", but worth taking a look for sure @Andrew - with debug symbols and backtrace it already makes more sense :-) (gdb) frame 1 #1 0x0000aaaaab04fd84 in qmp_query_cpu_model_expansion (type=, model=0xaaaaabcd91b0, errp=errp@entry=0xffffffffee60) at ./target/arm/monitor.c:140 140 int len = strlen(cpu_type) - strlen(ARM_CPU_TYPE_SUFFIX); (gdb) p cpu_type $1 = 0x0 This is from current_machine->cpu_type (gdb) p *current_machine $3 = {parent_obj = {class = 0xaaaaabc1aa30, free = 0xfffff7d21680 , properties = 0xaaaaabcc0cc0, ref = 2, parent = 0xaaaaabcc33d0}, sysbus_notifier = { notify = 0xaaaaab18f320 , node = {le_next = 0xaaaaabadaf20 , le_prev = 0xaaaaabb17558 }}, accel = 0xaaaaabcce080 "kvm", kernel_irqchip_allowed = true, kernel_irqchip_required = false, kernel_irqchip_split = false, kvm_shadow_mem = -1, dtb = 0x0, dumpdtb = 0x0, phandle_start = 0, dt_compatible = 0x0, dump_guest_core = true, mem_merge = true, usb = false, usb_disabled = false, igd_gfx_passthru = false, firmware = 0x0, iommu = false, suppress_vmdesc = false, enforce_config_section = false, enable_graphics = false, memory_encryption = 0x0, device_memory = 0x0, ram_size = 0, maxram_size = 0, ram_slots = 0, boot_order = 0x0, kernel_filename = 0x0, kernel_cmdline = 0xaaaaab700a78 "", initrd_filename = 0x0, cpu_type = 0x0, accelerator = 0xaaaaabccf820, possible_cpus = 0x0, smp = {cpus = 1, cores = 1, threads = 1, max_cpus = 1}, nvdimms_state = 0x0, numa_state = 0x0} So yes this is zero, but why is the question Also we need to compare this with Focal-ussuri which was mentioned to be working