various fixes for use with libmuser #1

jlevon · 2020-11-24T01:02:30Z

This is against https://github.com/nutanix/muser/tree/jlevon.sock-func-rework

With these fixes (and at least a couple of hacks), I get far enough to reach:

./x86_64-softmmu/qemu-system-x86_64 -D qemu.log -vnc :8000 -mem-prealloc -m 1024 -cpu kvm64 -smp 1 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=mem,share=yes,size=1073741824  -device vfio-user-pci,socket=/tmp/muser  ~/centos73_vdisk.qcow2
qemu-system-x86_64: -device vfio-user-pci,socket=/tmp/muser: warning: vfio VFIO user </tmp/muser>: Could not enable error recovery for the device
qemu-system-x86_64: Container 0x55a057183400 can't map guest IOVA region 0xc0000..0xcffff
qemu: hardware error: vfio: DMA mapping failed, unable to continue

via

#0  0x00005590afe9492c in vfio_user_dma_map (proxy=0x5590b1ea6bd0, map=map@entry=0x7ffc00c41330, fds=fds@entry=0x0, nelem=nelem@entry=1) at /home/john.levon/src/qemu/hw/vfio/user.c:553
#1  0x00005590afe82b8b in vfio_dma_map (container=container@entry=0x5590b1e49400, mr=0x5590b12122c0, iova=iova@entry=0, size=size@entry=655360, vaddr=vaddr@entry=0x7f3c36400000, readonly=<optimized out>)
    at /home/john.levon/src/qemu/hw/vfio/common.c:402
#2  0x00005590afe840ed in vfio_listener_region_add (listener=0x5590b1e49410, section=<optimized out>) at /home/john.levon/src/qemu/hw/vfio/common.c:752
#3  0x00005590afe23e5e in memory_listener_register (as=<optimized out>, listener=0x5590b1e49410) at /home/john.levon/src/qemu/memory.c:2679
#4  0x00005590afe23e5e in memory_listener_register (listener=listener@entry=0x5590b1e49410, as=<optimized out>) at /home/john.levon/src/qemu/memory.c:2746
#5  0x00005590afe8ec9b in vfio_user_pci_realize (pdev=0x5590b1ea57c0, errp=0x7ffc00c415d0) at /home/john.levon/src/qemu/hw/vfio/pci.c:3495
#6  0x00005590b0038da7 in pci_qdev_realize (qdev=0x5590b1ea57c0, errp=0x7ffc00c41670) at hw/pci/pci.c:2098

We're trying to map a region, but that region does not have VFIO_REGION_INFO_FLAG_MMAP, so its fd is not set (in fact, muser can't do that yet).

This is as far as I got today.

Signed-off-by: John Levon <[email protected]>

tmakatos · 2020-12-15T16:17:55Z

@jlevon I've hacked your code a bit further attempting to get SPDK run, I can't seem to be able to create a PR against your branch, could you cherry-pick the commits from https://github.com/tmakatos/qemu/tree/vfio-user-integration?

Signed-off-by: Thanos Makatos <[email protected]>

The kernel comes from debian archive so it's trusted. Invoking the test can be done as follows: $ avocado --show=app,console run -t machine:fuloong2e tests/acceptance/ (1/1) tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_fuloong2e: console: [ 0.000000] Initializing cgroup subsys cpuset console: [ 0.000000] Initializing cgroup subsys cpu console: [ 0.000000] Initializing cgroup subsys cpuacct console: [ 0.000000] Linux version 3.16.0-6-loongson-2e ([email protected]) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.56-1+deb8u1 (2018-05-08) console: [ 0.000000] memsize=256, highmemsize=0 console: [ 0.000000] CpuClock = 533080000 console: [ 0.000000] bootconsole [early0] enabled console: [ 0.000000] CPU0 revision is: 00006302 (ICT Loongson-2) console: [ 0.000000] FPU revision is: 00000501 console: [ 0.000000] Checking for the multiply/shift bug... no. console: [ 0.000000] Checking for the daddiu bug... no. console: [ 0.000000] Determined physical RAM map: console: [ 0.000000] memory: 0000000010000000 @ 0000000000000000 (usable) console: [ 0.000000] memory: 0000000004000000 @ 0000000010000000 (reserved) console: [ 0.000000] memory: 0000000003ffffff @ 000000001c000001 (reserved) console: [ 0.000000] Initrd not found or empty - disabling initrd console: [ 0.000000] Zone ranges: console: [ 0.000000] DMA [mem 0x00000000-0x00ffffff] console: [ 0.000000] Normal [mem 0x01000000-0x0fffffff] console: [ 0.000000] Movable zone start for each node console: [ 0.000000] Early memory node ranges console: [ 0.000000] node 0: [mem 0x00000000-0x0fffffff] console: [ 0.000000] Reserving 0MB of memory at 0MB for crashkernel console: [ 0.000000] Primary instruction cache 64kB, VIPT, direct mapped, linesize 32 bytes. console: [ 0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes console: [ 0.000000] Unified secondary cache 512kB 4-way, linesize 32 bytes. console: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16327 console: [ 0.000000] Kernel command line: printk.time=0 console=ttyS0 PASS (2.27 s) Signed-off-by: Jiaxun Yang <[email protected]> Reviewed-by: Wainer dos Santos Moschetta <[email protected]> Reviewed-by: Willian Rampazzo <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Tested-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> [PMD: Added command line example] Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

…eaks When running device-introspect-test, a memory leak occurred in the digic_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 3 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

…d memleaks When running device-introspect-test, a memory leak occurred in the a10_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 6 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278 #7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49 #11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_rtc_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 #10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 #11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 #12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_pwm_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 240 byte(s) in 5 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401 #7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

When running device-introspect-test, a memory leak occurred in the mss_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 2 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

When running device-introspect-test, a memory leak occurred in the mv88w8618_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 4 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862 #7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283 #12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_mct_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 #10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 #11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 #12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

When the length of mname is less than 5, memcpy("xenfv", mname, 5) will cause heap buffer overflow. Therefore, use strncmp to avoid this problem. The asan showed stack: ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f2f4 at pc 0x7f65d8cc2225 bp 0x7ffe93cc5a60 sp 0x7ffe93cc5208 READ of size 5 at 0x60200000f2f4 thread T0 #0 0x7f65d8cc2224 in memcmp (/lib64/libasan.so.5+0xdf224) #1 0x5632c20be95b in qtest_cb_for_every_machine tests/qtest/libqtest.c:1282 #2 0x5632c20b7995 in main tests/qtest/test-hmp.c:160 #3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42) #4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd) Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Laurent Vivier <[email protected]> Message-Id: <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

When running device-introspect-test, a memory leak occurred in the pl031_init function, this patch use timer_free() in the finalize function to fix it. ASAN shows memory leak stack: Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf5621cfc in timer_new_full qemu/include/qemu/timer.h:523 #3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544 #4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562 #5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194 #6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515 #7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729 #8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 #9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283 #10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801 #11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916 #12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Message-Id: <[email protected]> Signed-off-by: Laurent Vivier <[email protected]>

When running device-introspect-test, a memory leak occurred in the mos6522_init function, this patch use timer_free() in the finalize function to fix it. ASAN shows memory leak stack: Direct leak of 96 byte(s) in 2 object(s) allocated from: #0 0xfffd5fe9e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xfffd5f7b6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaae50303d0c in timer_new_full qemu/include/qemu/timer.h:523 #3 0xaaae50303d0c in timer_new qemu/include/qemu/timer.h:544 #4 0xaaae50303d0c in timer_new_ns qemu/include/qemu/timer.h:562 #5 0xaaae50303d0c in mos6522_init qemu/hw/misc/mos6522.c:490 #6 0xaaae50b77d70 in object_init_with_type qemu/qom/object.c:371 #7 0xaaae50b7ae84 in object_initialize_with_type qemu/qom/object.c:515 #8 0xaaae50b7b0f8 in object_new_with_type qemu/qom/object.c:729 #9 0xaaae50bb6d58 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 #10 0xaaae50d7e1dc in qmp_marshal_device_list_properties qemu/qapi/qapi-commands-qdev.c:59 #11 0xaaae50dc87a0 in do_qmp_dispatch_bh qemu/qapi/qmp-dispatch.c:110 #12 0xaaae50d931a0 in aio_bh_call qemu/util/async.c:136 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Acked-by: David Gibson <[email protected]> Reviewed-by: Peter Maydell <[email protected]> Message-Id: <[email protected]> Signed-off-by: Laurent Vivier <[email protected]>

The adc_qom_set function didn't free "response", which caused an indirect memory leak. So use qobject_unref() to fix it. ASAN shows memory leak stack: Indirect leak of 593280 byte(s) in 144 object(s) allocated from: #0 0x7f9a5e7e8d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e) #1 0x7f9a5e607a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50) #2 0x55b1bebf636b in qdict_new ../qobject/qdict.c:30 #3 0x55b1bec09699 in parse_object ../qobject/json-parser.c:318 #4 0x55b1bec0b2df in parse_value ../qobject/json-parser.c:546 #5 0x55b1bec0b6a9 in json_parser_parse ../qobject/json-parser.c:580 #6 0x55b1bec060d1 in json_message_process_token ../qobject/json-streamer.c:92 #7 0x55b1bec16a12 in json_lexer_feed_char ../qobject/json-lexer.c:313 #8 0x55b1bec16fbd in json_lexer_feed ../qobject/json-lexer.c:350 #9 0x55b1bec06453 in json_message_parser_feed ../qobject/json-streamer.c:121 #10 0x55b1bebc2d51 in qmp_fd_receive ../tests/qtest/libqtest.c:614 #11 0x55b1bebc2f5e in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636 #12 0x55b1bebc2e6c in qtest_qmp_receive ../tests/qtest/libqtest.c:624 #13 0x55b1bebc3340 in qtest_vqmp ../tests/qtest/libqtest.c:715 #14 0x55b1bebc3942 in qtest_qmp ../tests/qtest/libqtest.c:756 #15 0x55b1bebbd64a in adc_qom_set ../tests/qtest/npcm7xx_adc-test.c:127 #16 0x55b1bebbd793 in adc_write_input ../tests/qtest/npcm7xx_adc-test.c:140 #17 0x55b1bebbdf92 in test_convert_external ../tests/qtest/npcm7xx_adc-test.c:246 Reported-by: Euler Robot <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Hao Wu <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]>

The pwm_qom_get function didn't free "response", which caused an indirect memory leak. So use qobject_unref() to fix it. ASAN shows memory leak stack: Indirect leak of 74160000 byte(s) in 18000 object(s) allocated from: #0 0x7f96e2f79d4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e) #1 0x7f96e2d98a50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50) #2 0x556313112180 in qdict_new ../qobject/qdict.c:30 #3 0x556313115bca in parse_object ../qobject/json-parser.c:318 #4 0x556313117810 in parse_value ../qobject/json-parser.c:546 #5 0x556313117bda in json_parser_parse ../qobject/json-parser.c:580 #6 0x55631310fe67 in json_message_process_token ../qobject/json-streamer.c:92 #7 0x5563131210b7 in json_lexer_feed_char ../qobject/json-lexer.c:313 #8 0x556313121662 in json_lexer_feed ../qobject/json-lexer.c:350 #9 0x5563131101e9 in json_message_parser_feed ../qobject/json-streamer.c:121 #10 0x5563130cb81e in qmp_fd_receive ../tests/qtest/libqtest.c:614 #11 0x5563130cba2b in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636 #12 0x5563130cb939 in qtest_qmp_receive ../tests/qtest/libqtest.c:624 #13 0x5563130cbe0d in qtest_vqmp ../tests/qtest/libqtest.c:715 #14 0x5563130cc40f in qtest_qmp ../tests/qtest/libqtest.c:756 #15 0x5563130c5623 in pwm_qom_get ../tests/qtest/npcm7xx_pwm-test.c:180 #16 0x5563130c595e in pwm_get_duty ../tests/qtest/npcm7xx_pwm-test.c:210 #17 0x5563130c7529 in test_toggle ../tests/qtest/npcm7xx_pwm-test.c:447 Reported-by: Euler Robot <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gan Qixin <[email protected]> Reviewed-by: Havard Skinnemoen <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Hao Wu <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

This patch fixes the following memory leak detected by asan: Indirect leak of 560320 byte(s) in 136 object(s) allocated from: #0 0x556b3b3f9b57 in calloc (/home/stefanb/tmp/qemu-tip/build/tests/qtest/tpm-crb-swtpm-test+0x23fb57) #1 0x152b0e96b9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) #2 0x556b3b588f61 in parse_object /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:318:12 #3 0x556b3b588f61 in parse_value /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:546:16 #4 0x556b3b5886e8 in json_parser_parse /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:580:14 #5 0x556b3b52ff4a in json_message_process_token /home/stefanb/tmp/qemu-tip/build/../qobject/json-streamer.c:92:12 #6 0x556b3b59896f in json_lexer_feed_char /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:313:13 #7 0x556b3b598443 in json_lexer_feed /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:350:9 #8 0x556b3b436c70 in qmp_fd_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:614:9 #9 0x556b3b435871 in qtest_qmp_receive_dict /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:636:12 #10 0x556b3b435871 in qtest_qmp_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:624:27 #11 0x556b3b435c59 in qtest_vqmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:715:12 #12 0x556b3b435c59 in qtest_qmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:756:16 #13 0x556b3b4328c7 in tpm_util_wait_for_migration_complete /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-util.c:245:15 #14 0x556b3b4333be in tpm_test_swtpm_migration_test /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-tests.c:117:5 #15 0x152b0e98e29d (/lib64/libglib-2.0.so.0+0x7b29d) Signed-off-by: Stefan Berger <[email protected]> Cc: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Thomas Huth <[email protected]>

There are two cases that need to be accounted for when compiling QEMU for MinGW32: 1) A standalone distribution, where QEMU is self contained and extracted by the user, such as a user would download from the QEMU website. In this case, all the QEMU executable files should be rooted in $prefix to ensure they can be easily found by the user 2) QEMU integrated into a distribution image/sysroot/SDK and distributed with other programs. In this case, the provided arguments for bindir/datadir/etc. should be respected as they for a Linux build. Restructures the MinGW path configuration so that all of the paths except bindir use the same rules as when building for other platforms. This satisfies #2 and #1 since these files do not need to be directly in $prefix anyway. The handling for --bindir is changed so that it defaults to $prefix on MinGW (maintaining the compatibility with #1), but if the user specifies a specific path when configuring it can also satisfy #2. Signed-off-by: Joshua Watt <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>

Alexander reported an issue in gic_get_current_cpu() using the fuzzer. Yet another "deref current_cpu with QTest" bug, reproducible doing: $ echo readb 0xf03ff000 | qemu-system-arm -M npcm750-evb,accel=qtest -qtest stdio [I 1611849440.651452] OPENED [R +0.242498] readb 0xf03ff000 hw/intc/arm_gic.c:63:29: runtime error: member access within null pointer of type 'CPUState' (aka 'struct CPUState') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior hw/intc/arm_gic.c:63:29 in AddressSanitizer:DEADLYSIGNAL ================================================================= ==3719691==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000082a0 (pc 0x5618790ac882 bp 0x7ffca946f4f0 sp 0x7ffca946f4a0 T0) ==3719691==The signal is caused by a READ memory access. #0 0x5618790ac882 in gic_get_current_cpu hw/intc/arm_gic.c:63:29 #1 0x5618790a8901 in gic_dist_readb hw/intc/arm_gic.c:955:11 #2 0x5618790a7489 in gic_dist_read hw/intc/arm_gic.c:1158:17 #3 0x56187adc573b in memory_region_read_with_attrs_accessor softmmu/memory.c:464:9 #4 0x56187ad7903a in access_with_adjusted_size softmmu/memory.c:552:18 #5 0x56187ad766d6 in memory_region_dispatch_read1 softmmu/memory.c:1426:16 #6 0x56187ad758a8 in memory_region_dispatch_read softmmu/memory.c:1449:9 #7 0x56187b09e84c in flatview_read_continue softmmu/physmem.c:2822:23 #8 0x56187b0a0115 in flatview_read softmmu/physmem.c:2862:12 #9 0x56187b09fc9e in address_space_read_full softmmu/physmem.c:2875:18 #10 0x56187aa88633 in address_space_read include/exec/memory.h:2489:18 #11 0x56187aa88633 in qtest_process_command softmmu/qtest.c:558:13 #12 0x56187aa81881 in qtest_process_inbuf softmmu/qtest.c:797:9 #13 0x56187aa80e02 in qtest_read softmmu/qtest.c:809:5 current_cpu is NULL because QTest accelerator does not use CPU. Fix by skipping the check and returning the first CPU index when QTest accelerator is used, similarly to commit c781a2c ("hw/i386/vmport: Allow QTest use without crashing"). Reported-by: Alexander Bulekov <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Reviewed-by: Alexander Bulekov <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]>

When the reconnect in NBD client is in progress, the iochannel used for NBD connection doesn't exist. Therefore an attempt to detach it from the aio_context of the parent BlockDriverState results in a NULL pointer dereference. The problem is triggerable, in particular, when an outgoing migration is about to finish, and stopping the dataplane tries to move the BlockDriverState from the iothread aio_context to the main loop. If the NBD connection is lost before this point, and the NBD client has entered the reconnect procedure, QEMU crashes: #0 qemu_aio_coroutine_enter (ctx=0x5618056c7580, co=0x0) at /build/qemu-6MF7tq/qemu-5.0.1/util/qemu-coroutine.c:109 #1 0x00005618034b1b68 in nbd_client_attach_aio_context_bh ( opaque=0x561805ed4c00) at /build/qemu-6MF7tq/qemu-5.0.1/block/nbd.c:164 #2 0x000056180353116b in aio_wait_bh (opaque=0x7f60e1e63700) at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-wait.c:55 #3 0x0000561803530633 in aio_bh_call (bh=0x7f60d40a7e80) at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:136 #4 aio_bh_poll (ctx=ctx@entry=0x5618056c7580) at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:164 #5 0x0000561803533e5a in aio_poll (ctx=ctx@entry=0x5618056c7580, blocking=blocking@entry=true) at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-posix.c:650 #6 0x000056180353128d in aio_wait_bh_oneshot (ctx=0x5618056c7580, cb=<optimized out>, opaque=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/util/aio-wait.c:71 #7 0x000056180345c50a in bdrv_attach_aio_context (new_context=0x5618056c7580, bs=0x561805ed4c00) at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6172 #8 bdrv_set_aio_context_ignore (bs=bs@entry=0x561805ed4c00, new_context=new_context@entry=0x5618056c7580, ignore=ignore@entry=0x7f60e1e63780) at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6237 #9 0x000056180345c969 in bdrv_child_try_set_aio_context ( bs=bs@entry=0x561805ed4c00, ctx=0x5618056c7580, ignore_child=<optimized out>, errp=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6332 #10 0x00005618034957db in blk_do_set_aio_context (blk=0x56180695b3f0, new_context=0x5618056c7580, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /build/qemu-6MF7tq/qemu-5.0.1/block/block-backend.c:1989 #11 0x00005618034980bd in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /build/qemu-6MF7tq/qemu-5.0.1/block/block-backend.c:2010 #12 0x0000561803197953 in virtio_blk_data_plane_stop (vdev=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/hw/block/dataplane/virtio-blk.c:292 #13 0x00005618033d67bf in virtio_bus_stop_ioeventfd (bus=0x5618056d9f08) at /build/qemu-6MF7tq/qemu-5.0.1/hw/virtio/virtio-bus.c:245 #14 0x00005618031c9b2e in virtio_vmstate_change (opaque=0x5618056d9f90, running=0, state=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/hw/virtio/virtio.c:3220 #15 0x0000561803208bfd in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /build/qemu-6MF7tq/qemu-5.0.1/softmmu/vl.c:1275 #16 0x0000561803155c02 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/cpus.c:1032 #17 0x00005618033e3765 in migration_completion (s=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:2914 #18 migration_iteration_run (s=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3275 #19 migration_thread (opaque=opaque@entry=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3439 #20 0x0000561803536ad6 in qemu_thread_start (args=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/util/qemu-thread-posix.c:519 #21 0x00007f61085d06ba in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #22 0x00007f610830641d in sysctl () from /lib/x86_64-linux-gnu/libc.so.6 #23 0x0000000000000000 in ?? () Fix it by checking that the iochannel is non-null before trying to detach it from the aio_context. If it is null, no detaching is needed, and it will get reattached in the proper aio_context once the connection is reestablished. Signed-off-by: Roman Kagan <[email protected]> Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]> Message-Id: <[email protected]> Signed-off-by: Eric Blake <[email protected]>

When an NBD block driver state is moved from one aio_context to another (e.g. when doing a drain in a migration thread), nbd_client_attach_aio_context_bh is executed that enters the connection coroutine. However, the assumption that ->connection_co is always present here appears incorrect: the connection may have encountered an error other than -EIO in the underlying transport, and thus may have decided to quit rather than keep trying to reconnect, and therefore it may have terminated the connection coroutine. As a result an attempt to reassign the client in this state (NBD_CLIENT_QUIT) to a different aio_context leads to a null pointer dereference: #0 qio_channel_detach_aio_context (ioc=0x0) at /build/qemu-gYtjVn/qemu-5.0.1/io/channel.c:452 #1 0x0000562a242824b3 in bdrv_detach_aio_context (bs=0x562a268d6a00) at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6151 #2 bdrv_set_aio_context_ignore (bs=bs@entry=0x562a268d6a00, new_context=new_context@entry=0x562a260c9580, ignore=ignore@entry=0x7feeadc9b780) at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6230 #3 0x0000562a24282969 in bdrv_child_try_set_aio_context (bs=bs@entry=0x562a268d6a00, ctx=0x562a260c9580, ignore_child=<optimized out>, errp=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/block.c:6332 #4 0x0000562a242bb7db in blk_do_set_aio_context (blk=0x562a2735d0d0, new_context=0x562a260c9580, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /build/qemu-gYtjVn/qemu-5.0.1/block/block-backend.c:1989 #5 0x0000562a242be0bd in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /build/qemu-gYtjVn/qemu-5.0.1/block/block-backend.c:2010 #6 0x0000562a23fbd953 in virtio_blk_data_plane_stop (vdev=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/hw/block/dataplane/virtio-blk.c:292 #7 0x0000562a241fc7bf in virtio_bus_stop_ioeventfd (bus=0x562a260dbf08) at /build/qemu-gYtjVn/qemu-5.0.1/hw/virtio/virtio-bus.c:245 #8 0x0000562a23fefb2e in virtio_vmstate_change (opaque=0x562a260dbf90, running=0, state=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/hw/virtio/virtio.c:3220 #9 0x0000562a2402ebfd in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /build/qemu-gYtjVn/qemu-5.0.1/softmmu/vl.c:1275 #10 0x0000562a23f7bc02 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/cpus.c:1032 #11 0x0000562a24209765 in migration_completion (s=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:2914 #12 migration_iteration_run (s=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3275 #13 migration_thread (opaque=opaque@entry=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3439 #14 0x0000562a2435ca96 in qemu_thread_start (args=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/util/qemu-thread-posix.c:519 #15 0x00007feed31466ba in start_thread (arg=0x7feeadc9c700) at pthread_create.c:333 #16 0x00007feed2e7c41d in __GI___sysctl (name=0x0, nlen=608471908, oldval=0x562a2452b138, oldlenp=0x0, newval=0x562a2452c5e0 <__func__.28102>, newlen=0) at ../sysdeps/unix/sysv/linux/sysctl.c:30 #17 0x0000000000000000 in ?? () Fix it by checking that the connection coroutine is non-null before trying to enter it. If it is null, no entering is needed, as the connection is probably going down anyway. Signed-off-by: Roman Kagan <[email protected]> Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]> Message-Id: <[email protected]> Signed-off-by: Eric Blake <[email protected]>

Address space is destroyed without proper removal of its listeners with current code. They are expected to be removed in virtio_device_instance_finalize [1], but qemu calls it through object_deinit, after address_space_destroy call through device_set_realized [2]. Move it to virtio_device_unrealize, called before device_set_realized [3] and making it symmetric with memory_listener_register in virtio_device_realize. v2: Delete no-op call of virtio_device_instance_finalize. Add backtraces. [1] #0 virtio_device_instance_finalize (obj=0x555557de5120) at /home/qemu/include/hw/virtio/virtio.h:71 #1 0x0000555555b703c9 in object_deinit (type=0x555556639860, obj=<optimized out>) at ../qom/object.c:671 #2 object_finalize (data=0x555557de5120) at ../qom/object.c:685 #3 object_unref (objptr=0x555557de5120) at ../qom/object.c:1184 #4 0x0000555555b4de9d in bus_free_bus_child (kid=0x555557df0660) at ../hw/core/qdev.c:55 #5 0x0000555555c65003 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:281 Queued by: #0 bus_remove_child (bus=0x555557de5098, child=child@entry=0x555557de5120) at ../hw/core/qdev.c:60 #1 0x0000555555b4ee31 in device_unparent (obj=<optimized out>) at ../hw/core/qdev.c:984 #2 0x0000555555b70465 in object_finalize_child_property ( obj=<optimized out>, name=<optimized out>, opaque=0x555557de5120) at ../qom/object.c:1725 #3 0x0000555555b6fa17 in object_property_del_child ( child=0x555557de5120, obj=0x555557ddcf90) at ../qom/object.c:645 #4 object_unparent (obj=0x555557de5120) at ../qom/object.c:664 #5 0x0000555555b4c071 in bus_unparent (obj=<optimized out>) at ../hw/core/bus.c:147 #6 0x0000555555b70465 in object_finalize_child_property ( obj=<optimized out>, name=<optimized out>, opaque=0x555557de5098) at ../qom/object.c:1725 #7 0x0000555555b6fa17 in object_property_del_child ( child=0x555557de5098, obj=0x555557ddcf90) at ../qom/object.c:645 #8 object_unparent (obj=0x555557de5098) at ../qom/object.c:664 #9 0x0000555555b4ee19 in device_unparent (obj=<optimized out>) at ../hw/core/qdev.c:981 #10 0x0000555555b70465 in object_finalize_child_property ( obj=<optimized out>, name=<optimized out>, opaque=0x555557ddcf90) at ../qom/object.c:1725 #11 0x0000555555b6fa17 in object_property_del_child ( child=0x555557ddcf90, obj=0x55555685da10) at ../qom/object.c:645 #12 object_unparent (obj=0x555557ddcf90) at ../qom/object.c:664 #13 0x00005555558dc331 in pci_for_each_device_under_bus ( opaque=<optimized out>, fn=<optimized out>, bus=<optimized out>) at ../hw/pci/pci.c:1654 [2] Optimizer omits pci_qdev_unrealize, called by device_set_realized, and do_pci_unregister_device, called by pci_qdev_unrealize and caller of address_space_destroy. #0 address_space_destroy (as=0x555557ddd1b8) at ../softmmu/memory.c:2840 #1 0x0000555555b4fc53 in device_set_realized (obj=0x555557ddcf90, value=<optimized out>, errp=0x7fffeea8f1e0) at ../hw/core/qdev.c:850 #2 0x0000555555b6eaa6 in property_set_bool (obj=0x555557ddcf90, v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0, errp=0x7fffeea8f1e0) at ../qom/object.c:2255 #3 0x0000555555b70e07 in object_property_set ( obj=obj@entry=0x555557ddcf90, name=name@entry=0x555555db99df "realized", v=v@entry=0x7fffe46b7500, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/object.c:1400 #4 0x0000555555b73c5f in object_property_set_qobject ( obj=obj@entry=0x555557ddcf90, name=name@entry=0x555555db99df "realized", value=value@entry=0x7fffe44f6180, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/qom-qobject.c:28 #5 0x0000555555b71044 in object_property_set_bool ( obj=0x555557ddcf90, name=0x555555db99df "realized", value=<optimized out>, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 #6 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>, dev=0x555557ddcf90, opaque=<optimized out>) at /home/qemu/include/hw/qdev-core.h:17 #7 0x00005555558dc331 in pci_for_each_device_under_bus ( opaque=<optimized out>, fn=<optimized out>, bus=<optimized out>) at ../hw/pci/pci.c:1654 [3] #0 virtio_device_unrealize (dev=0x555557de5120) at ../hw/virtio/virtio.c:3680 #1 0x0000555555b4fc63 in device_set_realized (obj=0x555557de5120, value=<optimized out>, errp=0x7fffee28df90) at ../hw/core/qdev.c:850 #2 0x0000555555b6eab6 in property_set_bool (obj=0x555557de5120, v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0, errp=0x7fffee28df90) at ../qom/object.c:2255 #3 0x0000555555b70e17 in object_property_set ( obj=obj@entry=0x555557de5120, name=name@entry=0x555555db99ff "realized", v=v@entry=0x7ffdd8035040, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/object.c:1400 #4 0x0000555555b73c6f in object_property_set_qobject ( obj=obj@entry=0x555557de5120, name=name@entry=0x555555db99ff "realized", value=value@entry=0x7ffdd8035020, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/qom-qobject.c:28 #5 0x0000555555b71054 in object_property_set_bool ( obj=0x555557de5120, name=name@entry=0x555555db99ff "realized", value=value@entry=false, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 #6 0x0000555555b4edc5 in qdev_unrealize (dev=<optimized out>) at ../hw/core/qdev.c:403 #7 0x0000555555b4c2a9 in bus_set_realized (obj=<optimized out>, value=<optimized out>, errp=<optimized out>) at ../hw/core/bus.c:204 #8 0x0000555555b6eab6 in property_set_bool (obj=0x555557de5098, v=<optimized out>, name=<optimized out>, opaque=0x555557df04c0, errp=0x7fffee28e0a0) at ../qom/object.c:2255 #9 0x0000555555b70e17 in object_property_set ( obj=obj@entry=0x555557de5098, name=name@entry=0x555555db99ff "realized", v=v@entry=0x7ffdd8034f50, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/object.c:1400 #10 0x0000555555b73c6f in object_property_set_qobject ( obj=obj@entry=0x555557de5098, name=name@entry=0x555555db99ff "realized", value=value@entry=0x7ffdd8020630, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/qom-qobject.c:28 #11 0x0000555555b71054 in object_property_set_bool ( obj=obj@entry=0x555557de5098, name=name@entry=0x555555db99ff "realized", value=value@entry=false, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 #12 0x0000555555b4c725 in qbus_unrealize ( bus=bus@entry=0x555557de5098) at ../hw/core/bus.c:178 #13 0x0000555555b4fc00 in device_set_realized (obj=0x555557ddcf90, value=<optimized out>, errp=0x7fffee28e1e0) at ../hw/core/qdev.c:844 #14 0x0000555555b6eab6 in property_set_bool (obj=0x555557ddcf90, v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0, errp=0x7fffee28e1e0) at ../qom/object.c:2255 #15 0x0000555555b70e17 in object_property_set ( obj=obj@entry=0x555557ddcf90, name=name@entry=0x555555db99ff "realized", v=v@entry=0x7ffdd8020560, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/object.c:1400 #16 0x0000555555b73c6f in object_property_set_qobject ( obj=obj@entry=0x555557ddcf90, name=name@entry=0x555555db99ff "realized", value=value@entry=0x7ffdd8020540, errp=errp@entry=0x5555565bbf38 <error_abort>) at ../qom/qom-qobject.c:28 #17 0x0000555555b71054 in object_property_set_bool ( obj=0x555557ddcf90, name=0x555555db99ff "realized", value=<optimized out>, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 #18 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>, dev=0x555557ddcf90, opaque=<optimized out>) at /home/qemu/include/hw/qdev-core.h:17 #19 0x00005555558dc331 in pci_for_each_device_under_bus ( opaque=<optimized out>, fn=<optimized out>, bus=<optimized out>) at ../hw/pci/pci.c:1654 Fixes: c611c76 ("virtio: add MemoryListener to cache ring translations") Buglink: https://bugs.launchpad.net/qemu/+bug/1912846 Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Reviewed-by: Peter Xu <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>

Not checking this can lead to invalid dev->vdev member access in vhost_device_iotlb_miss if backend issue an iotlb message in a bad timing, either maliciously or by a bug. Reproduced rebooting a guest with testpmd in txonly forward mode. #0 0x0000559ffff94394 in vhost_device_iotlb_miss ( dev=dev@entry=0x55a0012f6680, iova=10245279744, write=1) at ../hw/virtio/vhost.c:1013 #1 0x0000559ffff9ac31 in vhost_backend_handle_iotlb_msg ( imsg=0x7ffddcfd32c0, dev=0x55a0012f6680) at ../hw/virtio/vhost-backend.c:411 #2 vhost_backend_handle_iotlb_msg (dev=dev@entry=0x55a0012f6680, imsg=imsg@entry=0x7ffddcfd32c0) at ../hw/virtio/vhost-backend.c:404 #3 0x0000559fffeded7b in slave_read (opaque=0x55a0012f6680) at ../hw/virtio/vhost-user.c:1464 #4 0x000055a0000c541b in aio_dispatch_handler ( ctx=ctx@entry=0x55a0010a2120, node=0x55a0012d9e00) at ../util/aio-posix.c:329 Fixes: 020e571 ("vhost: rework IOTLB messaging") Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Acked-by: Jason Wang <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>

jlevon · 2021-03-25T16:53:22Z

fixes long since merged in

Commit v5.2.0-190-g0546c0609c ("vl: split various early command line options to a separate function") moved the trace backend init code to the qemu_process_early_options(). Which is now being called before os_daemonize() via qemu_maybe_daemonize(). Turns out that this change of order causes a problem when executing QEMU in daemon mode and with CONFIG_TRACE_SIMPLE. The trace thread is now being created by the parent, and the parent is left waiting for a trace file flush that was registered via st_init(). The result is that the parent process never exits. To reproduce, fire up a QEMU process with -daemonize and with CONFIG_TRACE_SIMPLE enabled. Two QEMU process will be left in the host: $ sudo ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults \ -nographic -machine none,accel=kvm:tcg -daemonize $ ps axf | grep qemu 529710 pts/3 S+ 0:00 | \_ grep --color=auto qemu 529697 ? Ssl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize 529699 ? Sl 0:00 \_ ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize The parent thread is hang in flush_trace_file: $ sudo gdb ./x86_64-softmmu/qemu-system-x86_64 529697 (..) (gdb) bt #0 0x00007f9dac6a137d in syscall () at /lib64/libc.so.6 #1 0x00007f9dacc3c4f3 in g_cond_wait () at /lib64/libglib-2.0.so.0 #2 0x0000555d12f952da in flush_trace_file (wait=true) at ../trace/simple.c:140 #3 0x0000555d12f95b4c in st_flush_trace_buffer () at ../trace/simple.c:383 #4 0x00007f9dac5e43a7 in __run_exit_handlers () at /lib64/libc.so.6 #5 0x00007f9dac5e4550 in on_exit () at /lib64/libc.so.6 #6 0x0000555d12d454de in os_daemonize () at ../os-posix.c:255 #7 0x0000555d12d0bd5c in qemu_maybe_daemonize (pid_file=0x0) at ../softmmu/vl.c:2408 #8 0x0000555d12d0e566 in qemu_init (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/vl.c:3459 #9 0x0000555d128edac1 in main (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/main.c:49 (gdb) Aside from the 'zombie' process in the host, this is directly impacting Libvirt. Libvirt waits for the parent process to exit to be sure that the QMP monitor is available in the daemonized process to fetch QEMU capabilities, and as is now Libvirt hangs at daemon start waiting for the parent thread to exit. The fix is simple: just move the trace backend related code back to be executed after daemonizing. Fixes: 0546c06 Reviewed-by: Paolo Bonzini <[email protected]> Signed-off-by: Daniel Henrique Barboza <[email protected]> Message-Id: <[email protected]> Acked-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>

…ier() In the failover case configuration, virtio_net_device_realize() uses an add_migration_state_change_notifier() to add a state notifier, but this notifier is not removed by the unrealize function when the virtio-net card is unplugged. If the card is unplugged and a migration is started, the notifier is called and as it is not valid anymore QEMU crashes. This patch fixes the problem by adding the remove_migration_state_change_notifier() in virtio_net_device_unrealize(). The problem can be reproduced with: $ qemu-system-x86_64 -enable-kvm -m 1g -M q35 \ -device pcie-root-port,slot=4,id=root1 \ -device pcie-root-port,slot=5,id=root2 \ -device virtio-net-pci,id=net1,mac=52:54:00:6f:55:cc,failover=on,bus=root1 \ -monitor stdio disk.qcow2 (qemu) device_del net1 (qemu) migrate "exec:gzip -c > STATEFILE.gz" Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in () #1 0x0000555555d726d7 in notifier_list_notify (...) at .../util/notify.c:39 #2 0x0000555555842c1a in migrate_fd_connect (...) at .../migration/migration.c:3975 #3 0x0000555555950f7d in migration_channel_connect (...) error@entry=0x0) at .../migration/channel.c:107 #4 0x0000555555910922 in exec_start_outgoing_migration (...) at .../migration/exec.c:42 Reported-by: Igor Mammedov <[email protected]> Reviewed-by: Dr. David Alan Gilbert <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Laurent Vivier <[email protected]> Signed-off-by: Jason Wang <[email protected]>

Commit 3ca1f32 "block: BdrvChildClass: add .get_parent_aio_context handler" introduced new handler and commit 228ca37 "block: drop ctx argument from bdrv_root_attach_child" made a generic use of it. But 3ca1f32 didn't update child_vvfat_qcow. Fix that. Before that fix the command ./build/qemu-system-x86_64 -usb -device usb-storage,drive=fat16 \ -drive file=fat:rw:fat-type=16:"<path of a host folder>",id=fat16,format=raw,if=none crashes: 1 bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 2 bdrv_attach_child_common (child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, perm=3, shared_perm=4, opaque=0x559d62445690, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2795 3 bdrv_attach_child_noperm (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2855 4 bdrv_attach_child (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, errp=0x7ffc74c2ae60) at ../block.c:2953 5 bdrv_open_child (filename=0x559d62464b80 "/var/tmp/vl.h3TIS4", options=0x559d6246ec20, bdref_key=0x559d606f9e3d "write-target", parent=0x559d62445690, child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, allow_none=false, errp=0x7ffc74c2ae60) at ../block.c:3351 6 enable_write_target (bs=0x559d62445690, errp=0x7ffc74c2ae60) at ../block/vvfat.c:3176 7 vvfat_open (bs=0x559d62445690, options=0x559d6244adb0, flags=155650, errp=0x7ffc74c2ae60) at ../block/vvfat.c:1236 8 bdrv_open_driver (bs=0x559d62445690, drv=0x559d60d4f7e0 <bdrv_vvfat>, node_name=0x0, options=0x559d6244adb0, open_flags=155650, errp=0x7ffc74c2af70) at ../block.c:1557 9 bdrv_open_common (bs=0x559d62445690, file=0x0, options=0x559d6244adb0, errp=0x7ffc74c2af70) at ... (gdb) fr 1 #1 0x0000559d603ea3bf in bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 1440 return c->klass->get_parent_aio_context(c); (gdb) p c->klass $1 = (const BdrvChildClass *) 0x559d60c58d20 <child_vvfat_qcow> (gdb) p c->klass->get_parent_aio_context $2 = (AioContext *(*)(BdrvChild *)) 0x0 Fixes: 3ca1f32 Fixes: 228ca37 Reported-by: John Arbuckle <[email protected]> Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]> Message-Id: <[email protected]> Tested-by: John Arbuckle <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>

This patch fixes the following: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f6ae4559859 in __GI_abort () at abort.c:79 #2 0x0000559aaa386720 in error_exit (err=16, msg=0x559aaa5973d0 <__func__.16227> "qemu_mutex_destroy") at util/qemu-thread-posix.c:36 #3 0x0000559aaa3868c5 in qemu_mutex_destroy (mutex=0x559aabffe828) at util/qemu-thread-posix.c:69 #4 0x0000559aaa2f93a8 in char_finalize (obj=0x559aabffe800) at chardev/char.c:285 #5 0x0000559aaa23318a in object_deinit (obj=0x559aabffe800, type=0x559aabfd7d20) at qom/object.c:606 #6 0x0000559aaa2331b8 in object_deinit (obj=0x559aabffe800, type=0x559aabfd9060) at qom/object.c:610 #7 0x0000559aaa233200 in object_finalize (data=0x559aabffe800) at qom/object.c:620 #8 0x0000559aaa234202 in object_unref (obj=0x559aabffe800) at qom/object.c:1074 #9 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0dac10, name=0x559aac778760 "compare0-0", opaque=0x559aabffe800) at qom/object.c:1584 #10 0x0000559aaa232f70 in object_property_del_all (obj=0x559aac0dac10) at qom/object.c:557 #11 0x0000559aaa2331ed in object_finalize (data=0x559aac0dac10) at qom/object.c:619 #12 0x0000559aaa234202 in object_unref (obj=0x559aac0dac10) at qom/object.c:1074 #13 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0c75c0, name=0x559aac0dadc0 "chardevs", opaque=0x559aac0dac10) at qom/object.c:1584 #14 0x0000559aaa233071 in object_property_del_child (obj=0x559aac0c75c0, child=0x559aac0dac10, errp=0x0) at qom/object.c:580 #15 0x0000559aaa233155 in object_unparent (obj=0x559aac0dac10) at qom/object.c:599 #16 0x0000559aaa2fb721 in qemu_chr_cleanup () at chardev/char.c:1159 #17 0x0000559aa9f9b110 in main (argc=54, argv=0x7ffeb62fa998, envp=0x7ffeb62fab50) at vl.c:4539 When chardev is cleaned up, chr_write_lock needs to be destroyed. But the colo-compare module is not cleaned up normally before it when the guest poweroff. It is holding chr_write_lock at this time. This will cause qemu crash.So we add the function of colo_compare_cleanup() before qemu_chr_cleanup() to fix the bug. Signed-off-by: Lei Rao <[email protected]> Reviewed-by: Zhang Chen <[email protected]> Reviewed-by: Lukas Straub <[email protected]> Tested-by: Lukas Straub <[email protected]> Signed-off-by: Zhang Chen <[email protected]> Signed-off-by: Jason Wang <[email protected]>

While the SB16 seems to work up to 48000 Hz, the "Sound Blaster Series Hardware Programming Guide" limit the sampling range from 4000 Hz to 44100 Hz (Section 3-9, 3-10: Digitized Sound I/O Programming, tables 3-2 and 3-3). Later, section 6-15 (DSP Commands) is more specific regarding the 41h / 42h registers (Set digitized sound output sampling rate): Valid sampling rates range from 5000 to 45000 Hz inclusive. There is no comment regarding error handling if the register is filled with an out-of-range value. (See also section 3-28 "8-bit or 16-bit Auto-initialize Transfer"). Assume limits are enforced in hardware. This fixes triggering an assertion in audio_calloc(): #1 abort #2 audio_bug audio/audio.c:119:9 #3 audio_calloc audio/audio.c:154:9 #4 audio_pcm_sw_alloc_resources_out audio/audio_template.h:116:15 #5 audio_pcm_sw_init_out audio/audio_template.h:175:11 #6 audio_pcm_create_voice_pair_out audio/audio_template.h:410:9 #7 AUD_open_out audio/audio_template.h:503:14 #8 continue_dma8 hw/audio/sb16.c:216:20 #9 dma_cmd8 hw/audio/sb16.c:276:5 #10 command hw/audio/sb16.c:0 #11 dsp_write hw/audio/sb16.c:949:13 #12 portio_write softmmu/ioport.c:205:13 #13 memory_region_write_accessor softmmu/memory.c:491:5 #14 access_with_adjusted_size softmmu/memory.c:552:18 #15 memory_region_dispatch_write softmmu/memory.c:0:13 #16 flatview_write_continue softmmu/physmem.c:2759:23 #17 flatview_write softmmu/physmem.c:2799:14 #18 address_space_write softmmu/physmem.c:2891:18 #19 cpu_outw softmmu/ioport.c:70:5 [*] http://www.baudline.com/solutions/full_duplex/sb16_pci/index.html OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 Fixes: 85571bc ("audio merge (malc)") Buglink: https://bugs.launchpad.net/bugs/1910603 Tested-by: Qiang Liu <[email protected]> Reviewed-by: Qiang Liu <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Signed-off-by: Gerd Hoffmann <[email protected]>

backtrace: '0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 478 void *addr = mr->addr; (gdb) bt #0 0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 #1 0x0000555555891fcc in rdma_delete_block (block=<optimized out>, rdma=0x7fff38176010) at ../migration/rdma.c:691 #2 qemu_rdma_cleanup (rdma=0x7fff38176010) at ../migration/rdma.c:2365 #3 0x00005555558925b0 in qio_channel_rdma_close_rcu (rcu=0x555556b8b6c0) at ../migration/rdma.c:3073 #4 0x0000555555d652a3 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:281 #5 0x0000555555d5edf9 in qemu_thread_start (args=0x7fffe88bb4d0) at ../util/qemu-thread-posix.c:541 #6 0x00007ffff54c73f9 in start_thread () at /lib64/libpthread.so.0 #7 0x00007ffff53f3b03 in clone () at /lib64/libc.so.6 ' Signed-off-by: Li Zhijian <[email protected]> Message-Id: <[email protected]> Reviewed-by: Dr. David Alan Gilbert <[email protected]> Signed-off-by: Dr. David Alan Gilbert <[email protected]>

When building the Pegasos2 machine stand-alone we get: $ qemu-system-ppc -M pegasos2 -bios pegasos2.rom ERROR:qom/object.c:714:object_new_with_type: assertion failed: (type != NULL) Bail out! ERROR:qom/object.c:714:object_new_with_type: assertion failed: (type != NULL) Looking at the backtraces: Thread 1 "qemu-system-ppc" received signal SIGABRT, Aborted. (gdb) bt #0 0x00007ffff53877d5 in raise () at /lib64/libc.so.6 #1 0x00007ffff5370895 in abort () at /lib64/libc.so.6 #2 0x00007ffff6dc4b6c in g_assertion_message_expr.cold () at /lib64/libglib-2.0.so.0 #3 0x00007ffff6e229ff in g_assertion_message_expr () at /lib64/libglib-2.0.so.0 #4 0x0000555555a0c8f4 in object_new_with_type (type=0x0) at qom/object.c:714 #5 0x0000555555a0c9d5 in object_new (typename=0x555555c7afe4 "isa-pit") at qom/object.c:747 #6 0x0000555555a053b8 in qdev_new (name=0x555555c7afe4 "isa-pit") at hw/core/qdev.c:153 #7 0x00005555557cdd05 in isa_new (name=0x555555c7afe4 "isa-pit") at hw/isa/isa-bus.c:160 #8 0x00005555557cf518 in i8254_pit_init (bus=0x55555603d140, base=64, isa_irq=0, alt_irq=0x0) at include/hw/timer/i8254.h:54 #9 0x00005555557d12f9 in vt8231_realize (d=0x5555563d9770, errp=0x7fffffffcc28) at hw/isa/vt82c686.c:704 (gdb) bt #0 0x00007ffff54bd7d5 in raise () at /lib64/libc.so.6 #1 0x00007ffff54a6895 in abort () at /lib64/libc.so.6 #2 0x00005555558f7796 in object_new (typename=0x555555ad4889 "isa-parallel") at qom/object.c:749 #3 object_new (typename=type0x555555ad4889 "isa-parallel") at qom/object.c:743 #4 0x00005555558f0d46 in qdev_new (name=0x555555ad4889 "isa-parallel") at hw/core/qdev.c:153 #5 0x000055555576b669 in isa_new (name=0x555555ad4889 "isa-parallel") at hw/isa/isa-bus.c:160 #6 0x000055555576bbe8 in isa_superio_realize (dev=0x555555f15910, errp=<optimized out>) at hw/isa/isa-superio.c:54 #7 0x000055555576d5ed in via_superio_realize (d=0x555555f15910, errp=0x7fffffffcb30) at hw/isa/vt82c686.c:292 #8 0x00005555558f12c1 in device_set_realized (obj=<optimized out>, ...) at hw/core/qdev.c:761 #9 0x00005555558f5066 in property_set_bool (obj=0x555555f15910, ..., errp=0x7fffffffcbb0) at qom/object.c:2262 #10 0x00005555558f7f38 in object_property_set (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/object.c:1407 #11 0x00005555558fb2d0 in object_property_set_qobject (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/qom-qobject.c:28 #12 0x00005555558f8525 in object_property_set_bool (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/object.c:1477 #13 0x00005555558f18ee in qdev_realize (dev=0x555555f15910, bus=0x55555602a610, errp=<optimized out>) at hw/core/qdev.c:389 #14 0x00005555558f197f in qdev_realize_and_unref (dev=0x555555f15910, bus=0x55555602a610, errp=<optimized out>) at hw/core/qdev.c:396 #15 0x000055555576b709 in isa_realize_and_unref (errp=<optimized out>, bus=0x55555602a610, dev=0x555555f15910) at hw/isa/isa-bus.c:179 #16 isa_create_simple (bus=0x55555602a610, name=0x555555adc33b "vt8231-superio") at hw/isa/isa-bus.c:173 #17 0x000055555576d9b7 in vt8231_realize (d=0x555556186a50, errp=<optimized out>) at hw/isa/vt82c686.c:706 The "isa-pit" type (TYPE_I8254) and "isa-parallel" are missing. Add them. Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: BALATON Zoltan <[email protected]> Reviewed-by: Bin Meng <[email protected]> Message-Id: <[email protected]> [PMD: Added "isa-parallel" later]

When trying to use the pc-dimm device on a non-NUMA machine, we get: $ qemu-system-arm -M none -cpu max -S \ -object memory-backend-file,id=mem1,size=1M,mem-path=/tmp/1m \ -device pc-dimm,id=dimm1,memdev=mem1 Segmentation fault (core dumped) (gdb) bt #0 pc_dimm_realize (dev=0x555556da3e90, errp=0x7fffffffcd10) at hw/mem/pc-dimm.c:184 #1 0x0000555555fe1f8f in device_set_realized (obj=0x555556da3e90, value=true, errp=0x7fffffffce18) at hw/core/qdev.c:531 #2 0x0000555555feb4a9 in property_set_bool (obj=0x555556da3e90, v=0x555556e54420, name=0x5555563c3c41 "realized", opaque=0x555556a704f0, errp=0x7fffffffce18) at qom/object.c:2257 To avoid that crash, restrict the pc-dimm NUMA check to machines supporting NUMA, and do not allow the use of 'node' property on non-NUMA machines. Suggested-by: Igor Mammedov <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>

Without the previous commit, when running 'make check-qtest-i386' with QEMU configured with '--enable-sanitizers' we get: AddressSanitizer:DEADLYSIGNAL ================================================================= ==287878==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000344 ==287878==The signal is caused by a WRITE memory access. ==287878==Hint: address points to the zero page. #0 0x564b2e5bac27 in blk_inc_in_flight block/block-backend.c:1346:5 #1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 Add the reproducer for CVE-2021-20196. Suggested-by: Alexander Bulekov <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]>

The sanitizer reports: ==2534591==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600007f600 at pc 0x557ca6aede56 bp 0x7ffd98571600 sp 0x7ffd985715e0 WRITE of size 8 at 0x60600007f600 thread T0 #0 0x557ca6aede55 in vfio_connect_proxy /home/ctyun/workspace/code/qemu-5.0/hw/vfio/common.c:1936 oracle#1 0x557ca6b32d74 in vfio_user_pci_realize /home/ctyun/workspace/code/qemu-5.0/hw/vfio/pci.c:3649 oracle#2 0x557ca733c425 in pci_qdev_realize hw/pci/pci.c:2098 oracle#3 0x557ca7036370 in device_set_realized hw/core/qdev.c:891 oracle#4 0x557ca7709f27 in property_set_bool qom/object.c:2238 oracle#5 0x557ca771a01e in object_property_set_qobject qom/qom-qobject.c:26 oracle#6 0x557ca77120b8 in object_property_set_bool qom/object.c:1390 oracle#7 0x557ca6f2362e in qdev_device_add /home/ctyun/workspace/code/qemu-5.0/qdev-monitor.c:680 oracle#8 0x557ca6f2419f in qmp_device_add /home/ctyun/workspace/code/qemu-5.0/qdev-monitor.c:805 oracle#9 0x557ca6f24a78 in hmp_device_add /home/ctyun/workspace/code/qemu-5.0/qdev-monitor.c:905 oracle#10 0x557ca7572cdd in handle_hmp_command monitor/hmp.c:1082 oracle#11 0x557ca757323b in monitor_command_cb monitor/hmp.c:47 oracle#12 0x557ca7b0bfc2 in readline_handle_byte util/readline.c:408 oracle#13 0x557ca7573337 in monitor_read monitor/hmp.c:1312 oracle#14 0x557ca7927bee in mux_chr_read chardev/char-mux.c:228 oracle#15 0x557ca7920942 in fd_chr_read chardev/char-fd.c:68 oracle#16 0x7f3f7fa8e183 in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x51183) oracle#17 0x557ca7aa7caf in glib_pollfds_poll util/main-loop.c:219 oracle#18 0x557ca7aa7caf in os_host_main_loop_wait util/main-loop.c:242 oracle#19 0x557ca7aa7caf in main_loop_wait util/main-loop.c:518 oracle#20 0x557ca6c7e413 in qemu_main_loop /home/ctyun/workspace/code/qemu-5.0/softmmu/vl.c:1710 #21 0x557ca67570fd in main /home/ctyun/workspace/code/qemu-5.0/softmmu/main.c:49 #22 0x7f3f7e256b16 in __libc_start_main (/usr/lib64/libc.so.6+0x25b16) #23 0x557ca675a309 in _start (/root/sibs/qemu-system-x86_64+0x18d7309) 0x60600007f600 is located 32 bytes inside of 64-byte region [0x60600007f5e0,0x60600007f620) freed by thread T1 here: #0 0x7f3f7ff16c89 in free (/usr/lib64/libasan.so.4+0x151c89) oracle#1 0x7f3f7fa93fa8 in g_free (/usr/lib64/libglib-2.0.so.0+0x56fa8) oracle#2 0x557ca770f3bf in object_deinit qom/object.c:654 oracle#3 0x557ca770f3bf in object_finalize qom/object.c:668 oracle#4 0x557ca770f3bf in object_unref qom/object.c:1128 oracle#5 0x557ca7e669cf (/root/sibs/qemu-system-x86_64+0x2fe39cf) previously allocated by thread T0 here: #0 0x7f3f7ff1735b in calloc (/usr/lib64/libasan.so.4+0x15235b) oracle#1 0x7f3f7fa93f00 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x56f00) oracle#2 0x557ca733c425 in pci_qdev_realize hw/pci/pci.c:2098 Thread T1 created by T0 here: #0 0x7f3f7ff096ac in __interceptor_pthread_create (/usr/lib64/libasan.so.4+0x1446ac) oracle#1 0x557ca7abaf2f in qemu_thread_create util/qemu-thread-posix.c:556 SUMMARY: AddressSanitizer: heap-use-after-free /home/ctyun/workspace/code/qemu-5.0/hw/vfio/common.c:1936 in vfio_connect_proxy Signed-off-by: Bingsong Si <[email protected]>

Command "qemu-system-riscv64 -machine virt -m 2G -smp 1 -numa node,mem=1G -numa node,mem=1G" would trigger this problem.Backtrace with: #0 0x0000555555b5b1a4 in riscv_numa_get_default_cpu_node_id at ../hw/riscv/numa.c:211 #1 0x00005555558ce510 in machine_numa_finish_cpu_init at ../hw/core/machine.c:1230 #2 0x00005555558ce9d3 in machine_run_board_init at ../hw/core/machine.c:1346 #3 0x0000555555aaedc3 in qemu_init_board at ../softmmu/vl.c:2513 #4 0x0000555555aaf064 in qmp_x_exit_preconfig at ../softmmu/vl.c:2609 #5 0x0000555555ab1916 in qemu_init at ../softmmu/vl.c:3617 #6 0x000055555585463b in main at ../softmmu/main.c:47 This commit fixes the issue by adding parameter checks. Reviewed-by: Alistair Francis <[email protected]> Reviewed-by: Daniel Henrique Barboza <[email protected]> Reviewed-by: LIU Zhiwei <[email protected]> Reviewed-by: Weiwei Li <[email protected]> Signed-off-by: Yin Wang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Alistair Francis <[email protected]>

vhost_dev_start function does not release memory_listener object in case of an error. This may crash the guest when vhost is unable to set memory table: stack trace of thread 125653: Program terminated with signal SIGSEGV, Segmentation fault #0 memory_listener_register (qemu-kvm + 0x6cda0f) #1 vhost_dev_start (qemu-kvm + 0x699301) #2 vhost_net_start (qemu-kvm + 0x45b03f) #3 virtio_net_set_status (qemu-kvm + 0x665672) #4 qmp_set_link (qemu-kvm + 0x548fd5) #5 net_vhost_user_event (qemu-kvm + 0x552c45) #6 tcp_chr_connect (qemu-kvm + 0x88d473) #7 tcp_chr_new_client (qemu-kvm + 0x88cf83) #8 tcp_chr_accept (qemu-kvm + 0x88b429) #9 qio_net_listener_channel_func (qemu-kvm + 0x7ac07c) #10 g_main_context_dispatch (libglib-2.0.so.0 + 0x54e2f) Release memory_listener objects in the error path. Signed-off-by: Prasad Pandit <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Peter Xu <[email protected]> Fixes: c471ad0 ("vhost_net: device IOTLB support") Cc: [email protected] Acked-by: Jason Wang <[email protected]>

For some architectures like ARM64, multiple CPUs in one cluster can be associated with different NUMA nodes, which is irregular configuration because we shouldn't have this in baremetal environment. The irregular configuration causes Linux guest to misbehave, as the following warning messages indicate. -smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \ -numa node,nodeid=0,cpus=0-1,memdev=ram0 \ -numa node,nodeid=1,cpus=2-3,memdev=ram1 \ -numa node,nodeid=2,cpus=4-5,memdev=ram2 \ ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/sched/topology.c:2271 build_sched_domains+0x284/0x910 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-268.el9.aarch64 #1 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : build_sched_domains+0x284/0x910 lr : build_sched_domains+0x184/0x910 sp : ffff80000804bd50 x29: ffff80000804bd50 x28: 0000000000000002 x27: 0000000000000000 x26: ffff800009cf9a80 x25: 0000000000000000 x24: ffff800009cbf840 x23: ffff000080325000 x22: ffff0000005df800 x21: ffff80000a4ce508 x20: 0000000000000000 x19: ffff000080324440 x18: 0000000000000014 x17: 00000000388925c0 x16: 000000005386a066 x15: 000000009c10cc2e x14: 00000000000001c0 x13: 0000000000000001 x12: ffff00007fffb1a0 x11: ffff00007fffb180 x10: ffff80000a4ce508 x9 : 0000000000000041 x8 : ffff80000a4ce500 x7 : ffff80000a4cf920 x6 : 0000000000000001 x5 : 0000000000000001 x4 : 0000000000000007 x3 : 0000000000000002 x2 : 0000000000001000 x1 : ffff80000a4cf928 x0 : 0000000000000001 Call trace: build_sched_domains+0x284/0x910 sched_init_domains+0xac/0xe0 sched_init_smp+0x48/0xc8 kernel_init_freeable+0x140/0x1ac kernel_init+0x28/0x140 ret_from_fork+0x10/0x20 Improve the situation to warn when multiple CPUs in one cluster have been associated with different NUMA nodes. However, one NUMA node is allowed to be associated with different clusters. Signed-off-by: Gavin Shan <[email protected]> Acked-by: Philippe Mathieu-Daudé <[email protected]> Acked-by: Igor Mammedov <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>

When updating to the latest fedora the santizer found more leaks inside xkbmap: FAILED: pc-bios/keymaps/ar /builds/stsquad/qemu/build-oss-fuzz/qemu-keymap -f pc-bios/keymaps/ar -l ara ================================================================= ==3604==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1424 byte(s) in 1 object(s) allocated from: #0 0x56316418ebec in __interceptor_calloc (/builds/stsquad/qemu/build-oss-fuzz/qemu-keymap+0x127bec) (BuildId: a2ad9da3190962acaa010fa8f44a9269f9081e1c) #1 0x7f60d4dc067e (/lib64/libxkbcommon.so.0+0x1c67e) (BuildId: b243a34e4e58e6a30b93771c256268b114d34b80) #2 0x7f60d4dc2137 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e137) (BuildId: b243a34e4e58e6a30b93771c256268b114d34b80) #3 0x5631641ca50f in main /builds/stsquad/qemu/build-oss-fuzz/../qemu-keymap.c:215:11 and many more. As we can't do anything about the library add a suppression to keep the CI going with what its meant to be doing. Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Alex Bennée <[email protected]> Message-Id: <[email protected]>

in order to avoid requests being stuck in a BlockBackend's request queue during cleanup. Having such requests can lead to a deadlock [0] with a virtio-scsi-pci device using iothread that's busy with IO when initiating a shutdown with QMP 'quit'. There is a race where such a queued request can continue sometime (maybe after bdrv_child_free()?) during bdrv_root_unref_child() [1]. The completion will hold the AioContext lock and wait for the BQL during SCSI completion, but the main thread will hold the BQL and wait for the AioContext as part of bdrv_root_unref_child(), leading to the deadlock [0]. [0]: > Thread 3 (Thread 0x7f3bbd87b700 (LWP 135952) "qemu-system-x86"): > #0 __lll_lock_wait (futex=futex@entry=0x564183365f00 <qemu_global_mutex>, private=0) at lowlevellock.c:52 > #1 0x00007f3bc1c0d843 in __GI___pthread_mutex_lock (mutex=0x564183365f00 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 > #2 0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x564183365f00 <qemu_global_mutex>, file=0x564182b7f774 "../softmmu/physmem.c", line=2593) at ../util/qemu-thread-posix.c:94 > #3 0x000056418247cc2a in qemu_mutex_lock_iothread_impl (file=0x564182b7f774 "../softmmu/physmem.c", line=2593) at ../softmmu/cpus.c:504 > #4 0x00005641826d5325 in prepare_mmio_access (mr=0x5641856148a0) at ../softmmu/physmem.c:2593 > #5 0x00005641826d6fe7 in address_space_stl_internal (as=0x56418679b310, addr=4276113408, val=16418, attrs=..., result=0x0, endian=DEVICE_LITTLE_ENDIAN) at /home/febner/repos/qemu/memory_ldst.c.inc:318 > #6 0x00005641826d7154 in address_space_stl_le (as=0x56418679b310, addr=4276113408, val=16418, attrs=..., result=0x0) at /home/febner/repos/qemu/memory_ldst.c.inc:357 > #7 0x0000564182374b07 in pci_msi_trigger (dev=0x56418679b0d0, msg=...) at ../hw/pci/pci.c:359 > #8 0x000056418237118b in msi_send_message (dev=0x56418679b0d0, msg=...) at ../hw/pci/msi.c:379 > #9 0x0000564182372c10 in msix_notify (dev=0x56418679b0d0, vector=8) at ../hw/pci/msix.c:542 > #10 0x000056418243719c in virtio_pci_notify (d=0x56418679b0d0, vector=8) at ../hw/virtio/virtio-pci.c:77 > #11 0x00005641826933b0 in virtio_notify_vector (vdev=0x5641867a34a0, vector=8) at ../hw/virtio/virtio.c:1985 > #12 0x00005641826948d6 in virtio_irq (vq=0x5641867ac078) at ../hw/virtio/virtio.c:2461 > #13 0x0000564182694978 in virtio_notify (vdev=0x5641867a34a0, vq=0x5641867ac078) at ../hw/virtio/virtio.c:2473 > #14 0x0000564182665b83 in virtio_scsi_complete_req (req=0x7f3bb000e5d0) at ../hw/scsi/virtio-scsi.c:115 > #15 0x00005641826670ce in virtio_scsi_complete_cmd_req (req=0x7f3bb000e5d0) at ../hw/scsi/virtio-scsi.c:641 > #16 0x000056418266736b in virtio_scsi_command_complete (r=0x7f3bb0010560, resid=0) at ../hw/scsi/virtio-scsi.c:712 > #17 0x000056418239aac6 in scsi_req_complete (req=0x7f3bb0010560, status=2) at ../hw/scsi/scsi-bus.c:1526 > #18 0x000056418239e090 in scsi_handle_rw_error (r=0x7f3bb0010560, ret=-123, acct_failed=false) at ../hw/scsi/scsi-disk.c:242 > #19 0x000056418239e13f in scsi_disk_req_check_error (r=0x7f3bb0010560, ret=-123, acct_failed=false) at ../hw/scsi/scsi-disk.c:265 > #20 0x000056418239e482 in scsi_dma_complete_noio (r=0x7f3bb0010560, ret=-123) at ../hw/scsi/scsi-disk.c:340 > #21 0x000056418239e5d9 in scsi_dma_complete (opaque=0x7f3bb0010560, ret=-123) at ../hw/scsi/scsi-disk.c:371 > #22 0x00005641824809ad in dma_complete (dbs=0x7f3bb000d9d0, ret=-123) at ../softmmu/dma-helpers.c:107 > #23 0x0000564182480a72 in dma_blk_cb (opaque=0x7f3bb000d9d0, ret=-123) at ../softmmu/dma-helpers.c:127 > #24 0x00005641827bf78a in blk_aio_complete (acb=0x7f3bb00021a0) at ../block/block-backend.c:1563 > #25 0x00005641827bfa5e in blk_aio_write_entry (opaque=0x7f3bb00021a0) at ../block/block-backend.c:1630 > #26 0x000056418295638a in coroutine_trampoline (i0=-1342102448, i1=32571) at ../util/coroutine-ucontext.c:177 > #27 0x00007f3bc0caed40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #28 0x00007f3bbd8757f0 in ?? () > #29 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7f3bbe3e9280 (LWP 135944) "qemu-system-x86"): > #0 __lll_lock_wait (futex=futex@entry=0x5641856f2a00, private=0) at lowlevellock.c:52 > #1 0x00007f3bc1c0d8d1 in __GI___pthread_mutex_lock (mutex=0x5641856f2a00) at ../nptl/pthread_mutex_lock.c:115 > #2 0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x5641856f2a00, file=0x564182c0e319 "../util/async.c", line=728) at ../util/qemu-thread-posix.c:94 > #3 0x000056418293a140 in qemu_rec_mutex_lock_impl (mutex=0x5641856f2a00, file=0x564182c0e319 "../util/async.c", line=728) at ../util/qemu-thread-posix.c:149 > #4 0x00005641829532d5 in aio_context_acquire (ctx=0x5641856f29a0) at ../util/async.c:728 > #5 0x000056418279d5df in bdrv_set_aio_context_commit (opaque=0x5641856e6e50) at ../block.c:7493 > #6 0x000056418294e288 in tran_commit (tran=0x56418630bfe0) at ../util/transactions.c:87 > #7 0x000056418279d880 in bdrv_try_change_aio_context (bs=0x5641856f7130, ctx=0x56418548f810, ignore_child=0x0, errp=0x0) at ../block.c:7626 > #8 0x0000564182793f39 in bdrv_root_unref_child (child=0x5641856f47d0) at ../block.c:3242 > #9 0x00005641827be137 in blk_remove_bs (blk=0x564185709880) at ../block/block-backend.c:914 > #10 0x00005641827bd689 in blk_remove_all_bs () at ../block/block-backend.c:583 > #11 0x0000564182798699 in bdrv_close_all () at ../block.c:5117 > #12 0x000056418248a5b2 in qemu_cleanup () at ../softmmu/runstate.c:821 > #13 0x0000564182738603 in qemu_default_main () at ../softmmu/main.c:38 > #14 0x0000564182738631 in main (argc=30, argv=0x7ffd675a8a48) at ../softmmu/main.c:48 > > (gdb) p *((QemuMutex*)0x5641856f2a00) > $1 = {lock = {__data = {__lock = 2, __count = 2, __owner = 135952, ... > (gdb) p *((QemuMutex*)0x564183365f00) > $2 = {lock = {__data = {__lock = 2, __count = 0, __owner = 135944, ... [1]: > Thread 1 "qemu-system-x86" hit Breakpoint 5, bdrv_drain_all_end () at ../block/io.c:551 > #0 bdrv_drain_all_end () at ../block/io.c:551 > #1 0x00005569810f0376 in bdrv_graph_wrlock (bs=0x0) at ../block/graph-lock.c:156 > #2 0x00005569810bd3e0 in bdrv_replace_child_noperm (child=0x556982e2d7d0, new_bs=0x0) at ../block.c:2897 > #3 0x00005569810bdef2 in bdrv_root_unref_child (child=0x556982e2d7d0) at ../block.c:3227 > #4 0x00005569810e8137 in blk_remove_bs (blk=0x556982e42880) at ../block/block-backend.c:914 > #5 0x00005569810e7689 in blk_remove_all_bs () at ../block/block-backend.c:583 > #6 0x00005569810c2699 in bdrv_close_all () at ../block.c:5117 > #7 0x0000556980db45b2 in qemu_cleanup () at ../softmmu/runstate.c:821 > #8 0x0000556981062603 in qemu_default_main () at ../softmmu/main.c:38 > #9 0x0000556981062631 in main (argc=30, argv=0x7ffd7a82a418) at ../softmmu/main.c:48 > [Switching to Thread 0x7fe76dab2700 (LWP 103649)] > > Thread 3 "qemu-system-x86" hit Breakpoint 4, blk_inc_in_flight (blk=0x556982e42880) at ../block/block-backend.c:1505 > #0 blk_inc_in_flight (blk=0x556982e42880) at ../block/block-backend.c:1505 > #1 0x00005569810e8f36 in blk_wait_while_drained (blk=0x556982e42880) at ../block/block-backend.c:1312 > #2 0x00005569810e9231 in blk_co_do_pwritev_part (blk=0x556982e42880, offset=3422961664, bytes=4096, qiov=0x556983028060, qiov_offset=0, flags=0) at ../block/block-backend.c:1402 > #3 0x00005569810e9a4b in blk_aio_write_entry (opaque=0x556982e2cfa0) at ../block/block-backend.c:1628 > #4 0x000055698128038a in coroutine_trampoline (i0=-2090057872, i1=21865) at ../util/coroutine-ucontext.c:177 > #5 0x00007fe770f50d40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x00007ffd7a829570 in ?? () > #7 0x0000000000000000 in ?? () Signed-off-by: Fiona Ebner <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>

…ller/qemu-hppa into staging linux-user: Fix fcntl64() and accept4() for 32-bit targets A set of 3 patches: The first two patches fix fcntl64() and accept4(). the 3rd patch enhances the strace output for pread64/pwrite64(). This pull request does not includes Richard's mmap2 patch: https://patchew.org/QEMU/[email protected]/[email protected]/ Changes: v3: - added r-b from Richard to patches #1 and #2 v2: - rephrased commmit logs - return O_LARGFILE for fcntl() syscall too - dropped #ifdefs in accept4() patch - Dropped my mmap2() patch (former patch #3) - added r-b from Richard to 3rd patch Helge # -----BEGIN PGP SIGNATURE----- # # iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCZKl5RQAKCRD3ErUQojoP # X82sAQDnW53s7YkU4sZ1YREPWPVoCXZXgm587jTrmwT4v9AenQEAlbKdsw4hzzr/ # ptuKvgZfZaIp5QjBUl/Dh/CI5aVOLgc= # =hd4O # -----END PGP SIGNATURE----- # gpg: Signature made Sat 08 Jul 2023 03:57:09 PM BST # gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F # gpg: Good signature from "Helge Deller <[email protected]>" [unknown] # gpg: aka "Helge Deller <[email protected]>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603 # Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F * tag 'linux-user-fcntl64-pull-request' of https://github.com/hdeller/qemu-hppa: linux-user: Improve strace output of pread64() and pwrite64() linux-user: Fix accept4(SOCK_NONBLOCK) syscall linux-user: Fix fcntl() and fcntl64() to return O_LARGEFILE for 32-bit targets Signed-off-by: Richard Henderson <[email protected]>

We can fail the blk_insert_bs() at init_blk_migration(), leaving the BlkMigDevState without a dirty_bitmap and BlockDriverState. Account for the possibly missing elements when doing cleanup. Fix the following crashes: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 359 BlockDriverState *bs = bitmap->bs; #0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 #1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371 #2 0x0000555555bbad98 in block_migration_cleanup_bmds () at ../migration/block.c:681 Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) { #0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 #1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at ../block.c:7095 #2 0x0000555555bbae13 in block_migration_cleanup_bmds () at ../migration/block.c:690 Signed-off-by: Fabiano Rosas <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]>

virtio_load() as a whole should run in coroutine context because it reads from the migration stream and we don't want this to block. However, it calls virtio_set_features_nocheck() and devices don't expect their .set_features callback to run in a coroutine and therefore call functions that may not be called in coroutine context. To fix this, drop out of coroutine context for calling virtio_set_features_nocheck(). Without this fix, the following crash was reported: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007efc738c05d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007efc738477f3 in __GI_abort () at abort.c:79 #4 0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "", assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()", file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c", line=line@entry=275, function=function@entry=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:92 #5 0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf "!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275, function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:101 #6 0x0000560aebcd8dd6 in bdrv_register_buf () #7 0x0000560aeb97ed97 in ram_block_added.llvm () #8 0x0000560aebb8303f in ram_block_add.llvm () #9 0x0000560aebb834fa in qemu_ram_alloc_internal.llvm () #10 0x0000560aebb2ac98 in vfio_region_mmap () #11 0x0000560aebb3ea0f in vfio_bars_register () #12 0x0000560aebb3c628 in vfio_realize () #13 0x0000560aeb90f0c2 in pci_qdev_realize () #14 0x0000560aebc40305 in device_set_realized () #15 0x0000560aebc48e07 in property_set_bool.llvm () #16 0x0000560aebc46582 in object_property_set () #17 0x0000560aebc4cd58 in object_property_set_qobject () #18 0x0000560aebc46ba7 in object_property_set_bool () #19 0x0000560aeb98b3ca in qdev_device_add_from_qdict () #20 0x0000560aebb1fbaf in virtio_net_set_features () #21 0x0000560aebb46b51 in virtio_set_features_nocheck () #22 0x0000560aebb47107 in virtio_load () #23 0x0000560aeb9ae7ce in vmstate_load_state () #24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main () #25 0x0000560aeb9d45e1 in qemu_loadvm_state () #26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm () #27 0x0000560aebeace56 in coroutine_trampoline.llvm () Cc: [email protected] Buglink: https://issues.redhat.com/browse/RHEL-832 Signed-off-by: Kevin Wolf <[email protected]> Message-ID: <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Kevin Wolf <[email protected]>

Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 812 return con->hw_ops->ui_info != NULL; (gdb) bt #0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 #1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0, data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585 #2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at ../ui/vnc.c:1607 #3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN, opaque=0x5555578c76c0) at ../ui/vnc.c:1635 Fixes: https://issues.redhat.com/browse/RHEL-2600 Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Albert Esteve <[email protected]>

We can fail the blk_insert_bs() at init_blk_migration(), leaving the BlkMigDevState without a dirty_bitmap and BlockDriverState. Account for the possibly missing elements when doing cleanup. Fix the following crashes: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 359 BlockDriverState *bs = bitmap->bs; #0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 #1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371 #2 0x0000555555bbad98 in block_migration_cleanup_bmds () at ../migration/block.c:681 Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) { #0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 #1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at ../block.c:7095 #2 0x0000555555bbae13 in block_migration_cleanup_bmds () at ../migration/block.c:690 Signed-off-by: Fabiano Rosas <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]> (cherry picked from commit f187609) Signed-off-by: Michael Tokarev <[email protected]>

virtio_load() as a whole should run in coroutine context because it reads from the migration stream and we don't want this to block. However, it calls virtio_set_features_nocheck() and devices don't expect their .set_features callback to run in a coroutine and therefore call functions that may not be called in coroutine context. To fix this, drop out of coroutine context for calling virtio_set_features_nocheck(). Without this fix, the following crash was reported: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007efc738c05d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007efc738477f3 in __GI_abort () at abort.c:79 #4 0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "", assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()", file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c", line=line@entry=275, function=function@entry=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:92 #5 0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf "!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275, function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:101 #6 0x0000560aebcd8dd6 in bdrv_register_buf () #7 0x0000560aeb97ed97 in ram_block_added.llvm () #8 0x0000560aebb8303f in ram_block_add.llvm () #9 0x0000560aebb834fa in qemu_ram_alloc_internal.llvm () #10 0x0000560aebb2ac98 in vfio_region_mmap () #11 0x0000560aebb3ea0f in vfio_bars_register () #12 0x0000560aebb3c628 in vfio_realize () #13 0x0000560aeb90f0c2 in pci_qdev_realize () #14 0x0000560aebc40305 in device_set_realized () #15 0x0000560aebc48e07 in property_set_bool.llvm () #16 0x0000560aebc46582 in object_property_set () #17 0x0000560aebc4cd58 in object_property_set_qobject () #18 0x0000560aebc46ba7 in object_property_set_bool () #19 0x0000560aeb98b3ca in qdev_device_add_from_qdict () #20 0x0000560aebb1fbaf in virtio_net_set_features () #21 0x0000560aebb46b51 in virtio_set_features_nocheck () #22 0x0000560aebb47107 in virtio_load () #23 0x0000560aeb9ae7ce in vmstate_load_state () #24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main () #25 0x0000560aeb9d45e1 in qemu_loadvm_state () #26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm () #27 0x0000560aebeace56 in coroutine_trampoline.llvm () Cc: [email protected] Buglink: https://issues.redhat.com/browse/RHEL-832 Signed-off-by: Kevin Wolf <[email protected]> Message-ID: <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Kevin Wolf <[email protected]> (cherry picked from commit 92e2e6a) Signed-off-by: Michael Tokarev <[email protected]>

Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 812 return con->hw_ops->ui_info != NULL; (gdb) bt #0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 #1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0, data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585 #2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at ../ui/vnc.c:1607 #3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN, opaque=0x5555578c76c0) at ../ui/vnc.c:1635 Fixes: https://issues.redhat.com/browse/RHEL-2600 Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Albert Esteve <[email protected]> (cherry picked from commit 48a35e1) Signed-off-by: Michael Tokarev <[email protected]>

Since commit e99441a ("ui/curses: Do not use console_select()") qemu_text_console_put_keysym() no longer checks for NULL console argument, which leads to a later crash: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 332 } else if (s->echo && (keysym == '\r' || keysym == '\n')) { (gdb) bt #0 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at ../ui/console-vc.c:332 oracle#1 0x00005555559e18e5 in qemu_text_console_put_keysym (s=<optimized out>, keysym=<optimized out>) at ../ui/console.c:303 oracle#2 0x00005555559f2e88 in do_key_event (vs=vs@entry=0x5555579045c0, down=down@entry=1, keycode=keycode@entry=60, sym=sym@entry=65471) at ../ui/vnc.c:2034 oracle#3 0x00005555559f845c in ext_key_event (vs=0x5555579045c0, down=1, sym=65471, keycode=<optimized out>) at ../ui/vnc.c:2070 oracle#4 protocol_client_msg (vs=0x5555579045c0, data=<optimized out>, len=<optimized out>) at ../ui/vnc.c:2514 oracle#5 0x00005555559f515c in vnc_client_read (vs=0x5555579045c0) at ../ui/vnc.c:1607 Fixes: e99441a ("ui/curses: Do not use console_select()") Fixes: https://issues.redhat.com/browse/RHEL-50529 Cc: [email protected] Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Akihiko Odaki <[email protected]> Reviewed-by: Michael Tokarev <[email protected]> Signed-off-by: Michael Tokarev <[email protected]>

When SET_STREAM_FORMAT is called, we should clear the existing setup. Factor out common function to close a stream. Direct leak of 144 byte(s) in 3 object(s) allocated from: #0 0x7f91d38f7350 in calloc (/lib64/libasan.so.8+0xf7350) (BuildId: a4ad7eb954b390cf00f07fa10952988a41d9fc7a) oracle#1 0x7f91d2ab7871 in g_malloc0 (/lib64/libglib-2.0.so.0+0x64871) (BuildId: 36b60dbd02e796145a982d0151ce37202ec05649) oracle#2 0x562fa2f447ee in timer_new_full /home/elmarco/src/qemu/include/qemu/timer.h:538 oracle#3 0x562fa2f4486f in timer_new /home/elmarco/src/qemu/include/qemu/timer.h:559 oracle#4 0x562fa2f448a9 in timer_new_ns /home/elmarco/src/qemu/include/qemu/timer.h:577 oracle#5 0x562fa2f47955 in hda_audio_setup ../hw/audio/hda-codec.c:490 oracle#6 0x562fa2f4897e in hda_audio_command ../hw/audio/hda-codec.c:605 Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Akihiko Odaki <[email protected]> Message-ID: <[email protected]>

qemu-ga on a NetBSD -current VM terminates with a SIGSEGV upon receiving 'guest-set-time' command... Core was generated by `qemu-ga'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18) at ../qga/commands-posix.c:88 88 *str[len] = '\0'; [Current thread is 1 (process 1112)] (gdb) bt #0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20, str=str@entry=0xffffff922a18) at ../qga/commands-posix.c:88 oracle#1 0x000000000cd37b60 in ga_run_command (argv=argv@entry=0xffffff922a90, action=action@entry=0xcda34b8 "set hardware clock to system time", errp=errp@entry=0xffffff922a70, in_str=0x0) at ../qga/commands-posix.c:164 oracle#2 0x000000000cd380c4 in qmp_guest_set_time (has_time=<optimized out>, time_ns=<optimized out>, errp=errp@entry=0xffffff922ad0) at ../qga/commands-posix.c:304 oracle#3 0x000000000cd253d8 in qmp_marshal_guest_set_time (args=<optimized out>, ret=<optimized out>, errp=0xffffff922b48) at qga/qga-qapi-commands.c:193 oracle#4 0x000000000cd4e71c in qmp_dispatch (cmds=cmds@entry=0xcdf5b18 <ga_commands>, request=request@entry=0xf3c711a4b000, allow_oob=allow_oob@entry=false, cur_mon=cur_mon@entry=0x0) at ../qapi/qmp-dispatch.c:220 oracle#5 0x000000000cd36524 in process_event (opaque=0xf3c711a79000, obj=0xf3c711a4b000, err=0x0) at ../qga/main.c:677 oracle#6 0x000000000cd526f0 in json_message_process_token (lexer=lexer@entry=0xf3c711a79018, input=0xf3c712072480, type=type@entry=JSON_RCURLY, x=28, y=1) at ../qobject/json-streamer.c:99 oracle#7 0x000000000cd93860 in json_lexer_feed_char (lexer=lexer@entry=0xf3c711a79018, ch=125 '}', flush=flush@entry=false) at ../qobject/json-lexer.c:313 oracle#8 0x000000000cd93a00 in json_lexer_feed (lexer=lexer@entry=0xf3c711a79018, buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>) at ../qobject/json-lexer.c:350 oracle#9 0x000000000cd5290c in json_message_parser_feed (parser=parser@entry=0xf3c711a79000, buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n", size=<optimized out>) at ../qobject/json-streamer.c:121 oracle#10 0x000000000cd361fc in channel_event_cb (condition=<optimized out>, data=0xf3c711a79000) at ../qga/main.c:703 oracle#11 0x000000000cd3710c in ga_channel_client_event (channel=<optimized out>, condition=<optimized out>, data=0xf3c711b2d300) at ../qga/channel-posix.c:94 oracle#12 0x0000f3c7120d9bec in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0 oracle#13 0x0000f3c7120dd25c in g_main_context_iterate_unlocked.constprop () from /usr/pkg/lib/libglib-2.0.so.0 oracle#14 0x0000f3c7120ddbf0 in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0 oracle#15 0x000000000cda00d8 in run_agent_once (s=0xf3c711a79000) at ../qga/main.c:1522 oracle#16 run_agent (s=0xf3c711a79000) at ../qga/main.c:1559 oracle#17 main (argc=<optimized out>, argv=<optimized out>) at ../qga/main.c:1671 (gdb) The commandline options used on the host machine... qemu-system-aarch64 \ -machine type=virt,pflash0=rom \ -m 8G \ -cpu host \ -smp 8 \ -accel hvf \ -device virtio-net-pci,netdev=unet \ -device virtio-blk-pci,drive=hd \ -drive file=netbsd.qcow2,if=none,id=hd \ -netdev user,id=unet,hostfwd=tcp::2223-:22 \ -object rng-random,filename=/dev/urandom,id=viornd0 \ -device virtio-rng-pci,rng=viornd0 \ -serial mon:stdio \ -display none \ -blockdev node-name=rom,driver=file,filename=/opt/homebrew/Cellar/qemu/9.0.2/share/qemu/edk2-aarch64-code.fd,read-only=true \ -chardev socket,path=/tmp/qga_netbsd.sock,server=on,wait=off,id=qga0 \ -device virtio-serial \ -device virtconsole,chardev=qga0,name=org.qemu.guest_agent.0 This patch rectifies the operator precedence while assigning the NUL terminator. Fixes: c3f32c1 Signed-off-by: Sunil Nimmagadda <[email protected]> Reviewed-by: Konstantin Kostiuk <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Konstantin Kostiuk <[email protected]>

A bad (broken or malicious) 9p client (guest) could cause QEMU host to crash by sending a 9p 'Treaddir' request with a numeric file ID (FID) that was previously opened for a file instead of an expected directory: #0 0x0000762aff8f4919 in __GI___rewinddir (dirp=0xf) at ../sysdeps/unix/sysv/linux/rewinddir.c:29 oracle#1 0x0000557b7625fb40 in do_readdir_many (pdu=0x557bb67d2eb0, fidp=0x557bb67955b0, entries=0x762afe9fff58, offset=0, maxsize=131072, dostat=<optimized out>) at ../hw/9pfs/codir.c:101 oracle#2 v9fs_co_readdir_many (pdu=pdu@entry=0x557bb67d2eb0, fidp=fidp@entry=0x557bb67955b0, entries=entries@entry=0x762afe9fff58, offset=0, maxsize=131072, dostat=false) at ../hw/9pfs/codir.c:226 oracle#3 0x0000557b7625c1f9 in v9fs_do_readdir (pdu=0x557bb67d2eb0, fidp=0x557bb67955b0, offset=<optimized out>, max_count=<optimized out>) at ../hw/9pfs/9p.c:2488 oracle#4 v9fs_readdir (opaque=0x557bb67d2eb0) at ../hw/9pfs/9p.c:2602 That's because V9fsFidOpenState was declared as union type. So the same memory region is used for either an open POSIX file handle (int), or a POSIX DIR* pointer, etc., so 9p server incorrectly used the previously opened (valid) POSIX file handle (0xf) as DIR* pointer, eventually causing a crash in glibc's rewinddir() function. Root cause was therefore a missing check in 9p server's 'Treaddir' request handler, which must ensure that the client supplied FID was really opened as directory stream before trying to access the aforementioned union and its DIR* member. Cc: [email protected] Fixes: d62dbb5 ("virtio-9p: Add fidtype so that we can do type ...") Reported-by: Akihiro Suda <[email protected]> Tested-by: Akihiro Suda <[email protected]> Signed-off-by: Christian Schoenebeck <[email protected]> Reviewed-by: Greg Kurz <[email protected]> Message-Id: <[email protected]>

In extioi_setirq() we try to operate on a bit array stored as an array of uint32_t using the set_bit() and clear_bit() functions by casting the pointer to 'unsigned long *'. This has two problems: * the alignment of 'uint32_t' is less than that of 'unsigned long' so we pass an insufficiently aligned pointer, which is undefined behaviour * on big-endian hosts the 64-bit 'unsigned long' will have its two halves the wrong way around, and we will produce incorrect results The undefined behaviour is shown by the clang undefined-behaviour sanitizer when running the loongarch64-virt functional test: /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:5: runtime error: store to misaligned address 0x555559745d9c for type 'unsigned long', which requires 8 byte alignment 0x555559745d9c: note: pointer points here ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x555556fb81c4 in set_bit /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:9 oracle#1 0x555556fb81c4 in extioi_setirq /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_extioi.c:65:9 oracle#2 0x555556fb6e90 in pch_pic_irq_handler /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_pch_pic.c:75:5 oracle#3 0x555556710265 in serial_ioport_write /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/char/serial.c Fix these problems by using set_bit32() and clear_bit32(), which work with bit arrays stored as an array of uint32_t. Cc: [email protected] Fixes: cbff2db ("hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)") Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Bibo Mao <[email protected]> Message-id: [email protected]

In riscv_cpu_do_interrupt() we use the 'cause' value we got out of cs->exception as a shift value. However this value can be larger than 31, which means that "1 << cause" is undefined behaviour, because we do the shift on an 'int' type. This causes the undefined behaviour sanitizer to complain on one of the check-tcg tests: $ UBSAN_OPTIONS=print_stacktrace=1:abort_on_error=1:halt_on_error=1 ./build/clang/qemu-system-riscv64 -M virt -semihosting -display none -device loader,file=build/clang/tests/tcg/riscv64-softmmu/issue1060 ../../target/riscv/cpu_helper.c:1805:38: runtime error: shift exponent 63 is too large for 32-bit type 'int' #0 0x55f2dc026703 in riscv_cpu_do_interrupt /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../target/riscv/cpu_helper.c:1805:38 oracle#1 0x55f2dc3d170e in cpu_handle_exception /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../accel/tcg/cpu-exec.c:752:9 In this case cause is RISCV_EXCP_SEMIHOST, which is 0x3f. Use 1ULL instead to ensure that the shift is in range. Signed-off-by: Peter Maydell <[email protected]> Fixes: 1697837 ("target/riscv: Add M-mode virtual interrupt and IRQ filtering support.") Fixes: 40336d5 ("target/riscv: Add HS-mode virtual interrupt and IRQ filtering support.") Reviewed-by: Daniel Henrique Barboza <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Reviewed-by: Alistair Francis <[email protected]> Message-ID: <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

Found with test sbsaref introduced in [1]. [1] https://patchew.org/QEMU/[email protected]/ ../block/vvfat.c:433:24: runtime error: index 14 out of bounds for type 'uint8_t [11]' #0 0x56151a66b93a in create_long_filename ../block/vvfat.c:433 oracle#1 0x56151a66f3d7 in create_short_and_long_name ../block/vvfat.c:725 oracle#2 0x56151a670403 in read_directory ../block/vvfat.c:804 oracle#3 0x56151a674432 in init_directories ../block/vvfat.c:964 oracle#4 0x56151a67867b in vvfat_open ../block/vvfat.c:1258 oracle#5 0x56151a3b8e19 in bdrv_open_driver ../block.c:1660 oracle#6 0x56151a3bb666 in bdrv_open_common ../block.c:1985 oracle#7 0x56151a3cadb9 in bdrv_open_inherit ../block.c:4153 oracle#8 0x56151a3c8850 in bdrv_open_child_bs ../block.c:3731 oracle#9 0x56151a3ca832 in bdrv_open_inherit ../block.c:4098 oracle#10 0x56151a3cbe40 in bdrv_open ../block.c:4248 oracle#11 0x56151a46344f in blk_new_open ../block/block-backend.c:457 oracle#12 0x56151a388bd9 in blockdev_init ../blockdev.c:612 oracle#13 0x56151a38ab2d in drive_new ../blockdev.c:1006 oracle#14 0x5615190fca41 in drive_init_func ../system/vl.c:649 oracle#15 0x56151aa796dd in qemu_opts_foreach ../util/qemu-option.c:1135 oracle#16 0x5615190fd2b6 in configure_blockdev ../system/vl.c:708 oracle#17 0x56151910a307 in qemu_create_early_backends ../system/vl.c:2004 oracle#18 0x561519113fcf in qemu_init ../system/vl.c:3685 oracle#19 0x56151a7e438e in main ../system/main.c:47 oracle#20 0x7f72d1a46249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #21 0x7f72d1a46304 in __libc_start_main_impl ../csu/libc-start.c:360 #22 0x561517e98510 in _start (/home/user/.work/qemu/build/qemu-system-aarch64+0x3b9b510) The offset used can easily go beyond entry->name size. It's probably a bug, but I don't have the time to dive into vfat specifics for now. This change solves the ubsan issue, and is functionally equivalent, as anything written past the entry->name array would not be read anyway. Signed-off-by: Pierrick Bouvier <[email protected]> Reviewed-by: Michael Tokarev <[email protected]> Signed-off-by: Michael Tokarev <[email protected]>

jlevon added 4 commits November 24, 2020 00:55

various fixes for use with libmuser

969b38c

Signed-off-by: John Levon <[email protected]>

fix null deref in vfio_user_dma_map

17c707e

remove debug

5f1dda6

fix IRQ setting to use the right msg, actually pass eventfds

33cce83

tmakatos added 2 commits December 15, 2020 16:38

incomplete (?) hack to receive FDs

ab702c6

hack to avoid assertion failure

ff1970b

Signed-off-by: Thanos Makatos <[email protected]>

jlevon closed this Mar 25, 2021

bingsong mentioned this pull request May 22, 2023

vfio/pci: Fix VFIOGroup use after free #14

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

various fixes for use with libmuser #1

various fixes for use with libmuser #1

jlevon commented Nov 24, 2020

tmakatos commented Dec 15, 2020

jlevon commented Mar 25, 2021

various fixes for use with libmuser #1

various fixes for use with libmuser #1

Conversation

jlevon commented Nov 24, 2020

tmakatos commented Dec 15, 2020

jlevon commented Mar 25, 2021