Testing/docker binfmt tweaks #2

stsquad · 2020-01-21T14:23:33Z

test to trigger this

Instead of allocating make this entirely static. We shall reduce the size of the structure in later commits and dynamically allocate parts of it. We introduce an init and reset helper function to keep all the manipulation in one place. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> --- v2 - made entirely static, dropped dh/rth r-b tags due to changes

We only have one GDBState which should be allocated at the time we process any commands. This will make further clean-up a bit easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v3 - remove final *s paramters from function calls v4 - a few fixups for coding style

Rather than having a static buffer replace str_buf with a GString which we know can grow on demand. Convert the internal functions to take a GString instead of a char * and length. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Tested-by: Damien Hedde <damien.hedde@greensocs.com> --- v2 - fix conflict from status gdbserver_state - add put_strbuf helper v3 - remove double ;;

This is in preparation for further re-factoring of the register API with the rest of the code. Theoretically the read register function could overwrite the MAX_PACKET_LENGTH buffer although currently all registers are well within the size range. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Tested-by: Damien Hedde <damien.hedde@greensocs.com> --- v4 - don't set_set to len on rcmd (it's zeroed before we get here) v3 - fixed up email on Damien's tags

Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - take care of endianess of the whole 128 bit word

This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - make sure we pass hi/lo correctly as quads are stored in LE order

This is cleaner than poking memory directly and will make later clean-ups easier. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> --- v3 - fix mem_buf references - fix mem_buf + len cases

Instead of passing a pointer to memory now just extend the GByteArray to all the read register helpers. They can then safely append their data through the normal way. We don't bother with this abstraction for write registers as we have already ensured the buffer being copied from is the correct size. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v4 - fix mem_buf calculation for ppc_maybe_bswap_register v5 - introduce gdb_get_reg_ptr and use for ppc

We will want to generate similar dynamic XML for gdbstub support of SVE registers (the upstream doesn't use XML). To that end lightly rename a few things to make the distinction. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

This is described as optional but I'm not convinced of the numbering when multiple target fragments are sent. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - post inc param->n in place so we don't get out count wrong

The Linux kernel chooses the default of 64 bytes for SVE registers on the basis that it is the largest size on known hardware that won't grow the signal frame. We still honour the sve-max-vq property and userspace can expand the number of lanes by calling PR_SVE_SET_VL. This should not make any difference to SVE enabled software as the SVE is of course vector length agnostic. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - tweak zcr_el[1] instead

We also expose a the helpers to read/write the the registers. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- v2 - instead of zNpM expose zN at sve_max_vq width - wrap union in union q(us), d(usf), s(usf), h(usf), b(us) v3 - add a vg pseudo register for current width - spacing fixes - use switch/case for whole group - drop fpsr_pos marker - remove unused variables v4 - const-ify vec_lanes - drop vg

We will need this for some tests later. The docker images already support it by default. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

For system emulation we need to check the state of the GIC before we report the value. However this isn't relevant to exporting of the value to linux-user and indeed breaks the exported value as set by modify_arm_cp_regs. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - extend the ifdef and make type CONST with no accessfn

This tests a bunch of registers that the kernel allows userspace to read including the CPUID registers. We need a SVE aware compiler as we are testing the id_aa64zfr0_el1 register in the set. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20190205190224.2198-7-alex.bennee@linaro.org> --- vgdbstub - don't build unless using docker or CROSS_CC_HAS_SVE

This is useful, especially when testing relatively new gdbstub features that might not be in distro packages yet. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

The test runners job is to start QEMU with guest debug enabled and then spawn a gdb process running a test script that exercises the functionality it wants to test. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

A very simple test case which sets and reads SVE registers while running a test case. We don't really need to compile a SVE binary for this case but we will later so keep it simple for now. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- v5 - properly plumb in - skip if fails to connect

This is a fairly bare-bones test of setting the various vector sizes for SVE which will only fail if the PR_SVE_SET_VL can't reduce the user-space vector length by powers of 2. However we will also be able to use it in a future test which exercises the GDB stub. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- v3 - use index to fill zreg - CROSS_CC_HAS_SVE v5 - merge conflicts

This test exercises the gdbstub while runing the sve-iotcl test. I haven't plubmed it into make system as we need a way of verifying if gdb has the right support for SVE. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> --- v4 - interrogate ZCR_EL1 directly as no longer have vg v5 - plumb in - skip if fails to connect

Remove the packet size upper limit by using a GByteArray instead of a statically allocated array for last_packet. Thus we can now send big packets. Also remove the last_packet_len field and use last_packet->len instead. Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191211160514.58373-2-damien.hedde@greensocs.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Since we can now send packets of arbitrary length: simplify gdb_monitor_write() and send the whole payload in one packet. Suggested-by: Luc Michel <luc.michel@greensocs.com> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20191211160514.58373-3-damien.hedde@greensocs.com>

This is a bit more efficient than having to allocate and free memory for each item. The default size (60) is enough for all the existing incompatible features. Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Alberto Garcia <berto@igalia.com> Message-Id: <20200114145437.28382-1-berto@igalia.com>

When we are copying we want to ensure we grab the first resolution (the found in path section). However even that binary might be a symlink so lets make sure we chase the symlinks to copy the right binary to where it can be found. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak stack is as follow: Direct leak of 14336 byte(s) in 2 object(s) allocated from: #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624) /mnt/sdb/qemu/hw/virtio/virtio.c:2327 qemu#3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7) /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209 qemu#4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6) /mnt/sdb/qemu/hw/virtio/virtio.c:3504 qemu#5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37) /mnt/sdb/qemu/hw/core/qdev.c:876 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Greg Kurz <groug@kaod.org>

This patch fix memleaks when attaching/detaching virtio-scsi device, the memory leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 qemu#3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912 qemu#4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924 qemu#5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 qemu#6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224) /mnt/sdb/qemu/hw/core/qdev.c:865 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This patch save receive/transmit vq pointer in realize() and cleanup vqs through those vq pointers in unrealize(). The leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 qemu#3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208) /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339 qemu#4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 qemu#5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65) /mnt/sdb/qemu/hw/core/qdev.c:865 qemu#6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41) /mnt/sdb/qemu/qom/object.c:2102 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Message-Id: <20200115062535.50644-1-pannengyuan@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

When adding new devices implementing QOM interfaces, we might forgot to add the Kconfig dependency that pulls the required objects in when building. Since QOM dependencies are resolved at runtime, we don't get any link-time failures, and QEMU aborts while starting: $ qemu ... Segmentation fault (core dumped) (gdb) bt #0 0x00007ff6e96b1e35 in raise () from /lib64/libc.so.6 #1 0x00007ff6e969c895 in abort () from /lib64/libc.so.6 #2 0x00005572bc5051cf in type_initialize (ti=0x5572be6f1200) at qom/object.c:323 qemu#3 0x00005572bc505074 in type_initialize (ti=0x5572be6f1800) at qom/object.c:301 qemu#4 0x00005572bc505074 in type_initialize (ti=0x5572be6e48e0) at qom/object.c:301 qemu#5 0x00005572bc506939 in object_class_by_name (typename=0x5572bc56109a) at qom/object.c:959 qemu#6 0x00005572bc503dd5 in cpu_class_by_name (typename=0x5572bc56109a, cpu_model=0x5572be6d9930) at hw/core/cpu.c:286 Since the caller has access to the qdev parent/interface names, we can simply display them to avoid starting a debugger: $ qemu ... qemu: missing interface 'fancy-if' for object 'fancy-dev' Aborted (core dumped) This commit is similar to e02bdf1 ("Display more helpful message when an object type is missing"). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200118162348.17823-1-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

This patch fix memleaks when attaching/detaching virtio-scsi device, the memory leak stack is as follow: Direct leak of 21504 byte(s) in 3 object(s) allocated from: #0 0x7f491f2f2970 (/lib64/libasan.so.5+0xef970) ??:? #1 0x7f491e94649d (/lib64/libglib-2.0.so.0+0x5249d) ??:? #2 0x564d0f3919fa (./x86_64-softmmu/qemu-system-x86_64+0x2c3e9fa) /mnt/sdb/qemu/hw/virtio/virtio.c:2333 qemu#3 0x564d0f2eca55 (./x86_64-softmmu/qemu-system-x86_64+0x2b99a55) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:912 qemu#4 0x564d0f2ece7b (./x86_64-softmmu/qemu-system-x86_64+0x2b99e7b) /mnt/sdb/qemu/hw/scsi/virtio-scsi.c:924 qemu#5 0x564d0f39ee47 (./x86_64-softmmu/qemu-system-x86_64+0x2c4be47) /mnt/sdb/qemu/hw/virtio/virtio.c:3531 qemu#6 0x564d0f980224 (./x86_64-softmmu/qemu-system-x86_64+0x322d224) /mnt/sdb/qemu/hw/core/qdev.c:865 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20200117075547.60864-2-pannengyuan@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

All paths that lead to bdrv_backup_top_drop(), except for the call from backup_clean(), imply that the BDS AioContext has already been acquired, so doing it there too can potentially lead to QEMU hanging on AIO_WAIT_WHILE(). An easy way to trigger this situation is by issuing a two actions transaction, with a proper and a bogus blockdev-backup, so the second one will trigger a rollback. This will trigger a hang with an stack trace like this one: #0 0x00007fb680c75016 in __GI_ppoll (fds=0x55e74580f7c0, nfds=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39 #1 0x000055e743386e09 in ppoll (__ss=0x0, __timeout=0x0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 #2 0x000055e743386e09 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at util/qemu-timer.c:336 qemu#3 0x000055e743388dc4 in aio_poll (ctx=0x55e7458925d0, blocking=blocking@entry=true) at util/aio-posix.c:669 qemu#4 0x000055e743305dea in bdrv_flush (bs=bs@entry=0x55e74593c0d0) at block/io.c:2878 qemu#5 0x000055e7432be58e in bdrv_close (bs=0x55e74593c0d0) at block.c:4017 qemu#6 0x000055e7432be58e in bdrv_delete (bs=<optimized out>) at block.c:4262 qemu#7 0x000055e7432be58e in bdrv_unref (bs=bs@entry=0x55e74593c0d0) at block.c:5644 qemu#8 0x000055e743316b9b in bdrv_backup_top_drop (bs=bs@entry=0x55e74593c0d0) at block/backup-top.c:273 qemu#9 0x000055e74331461f in backup_job_create (job_id=0x0, bs=bs@entry=0x55e7458d5820, target=target@entry=0x55e74589f640, speed=0, sync_mode=MIRROR_SYNC_MODE_FULL, sync_bitmap=sync_bitmap@entry=0x0, bitmap_mode=BITMAP_SYNC_MODE_ON_SUCCESS, compress=false, filter_node_name=0x0, on_source_error=BLOCKDEV_ON_ERROR_REPORT, on_target_error=BLOCKDEV_ON_ERROR_REPORT, creation_flags=0, cb=0x0, opaque=0x0, txn=0x0, errp=0x7ffddfd1efb0) at block/backup.c:478 qemu#10 0x000055e74315bc52 in do_backup_common (backup=backup@entry=0x55e746c066d0, bs=bs@entry=0x55e7458d5820, target_bs=target_bs@entry=0x55e74589f640, aio_context=aio_context@entry=0x55e7458a91e0, txn=txn@entry=0x0, errp=errp@entry=0x7ffddfd1efb0) at blockdev.c:3580 qemu#11 0x000055e74315c37c in do_blockdev_backup (backup=backup@entry=0x55e746c066d0, txn=0x0, errp=errp@entry=0x7ffddfd1efb0) at /usr/src/debug/qemu-kvm-4.2.0-2.module+el8.2.0+5135+ed3b2489.x86_64/./qapi/qapi-types-block-core.h:1492 qemu#12 0x000055e74315c449 in blockdev_backup_prepare (common=0x55e746a8de90, errp=0x7ffddfd1f018) at blockdev.c:1885 qemu#13 0x000055e743160152 in qmp_transaction (dev_list=<optimized out>, has_props=<optimized out>, props=0x55e7467fe2c0, errp=errp@entry=0x7ffddfd1f088) at blockdev.c:2340 qemu#14 0x000055e743287ff5 in qmp_marshal_transaction (args=<optimized out>, ret=<optimized out>, errp=0x7ffddfd1f0f8) at qapi/qapi-commands-transaction.c:44 qemu#15 0x000055e74333de6c in do_qmp_dispatch (errp=0x7ffddfd1f0f0, allow_oob=<optimized out>, request=<optimized out>, cmds=0x55e743c28d60 <qmp_commands>) at qapi/qmp-dispatch.c:132 qemu#16 0x000055e74333de6c in qmp_dispatch (cmds=0x55e743c28d60 <qmp_commands>, request=<optimized out>, allow_oob=<optimized out>) at qapi/qmp-dispatch.c:175 qemu#17 0x000055e74325c061 in monitor_qmp_dispatch (mon=0x55e745908030, req=<optimized out>) at monitor/qmp.c:145 qemu#18 0x000055e74325c6fa in monitor_qmp_bh_dispatcher (data=<optimized out>) at monitor/qmp.c:234 qemu#19 0x000055e743385866 in aio_bh_call (bh=0x55e745807ae0) at util/async.c:117 qemu#20 0x000055e743385866 in aio_bh_poll (ctx=ctx@entry=0x55e7458067a0) at util/async.c:117 qemu#21 0x000055e743388c54 in aio_dispatch (ctx=0x55e7458067a0) at util/aio-posix.c:459 qemu#22 0x000055e743385742 in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:260 qemu#23 0x00007fb68543e67d in g_main_dispatch (context=0x55e745893a40) at gmain.c:3176 qemu#24 0x00007fb68543e67d in g_main_context_dispatch (context=context@entry=0x55e745893a40) at gmain.c:3829 qemu#25 0x000055e743387d08 in glib_pollfds_poll () at util/main-loop.c:219 qemu#26 0x000055e743387d08 in os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:242 qemu#27 0x000055e743387d08 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:518 qemu#28 0x000055e74316a3c1 in main_loop () at vl.c:1828 qemu#29 0x000055e743016a72 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4504 Fix this by not acquiring the AioContext there, and ensuring all paths leading to it have it already acquired (backup_clean()). RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1782111 Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

When running device-introspect-test, a memory leak occurred in the s390_cpu_initfn function, this patch use timer_free() in the finalize function to fix it. ASAN shows memory leak stack: Direct leak of 3552 byte(s) in 74 object(s) allocated from: #0 0xfffeb3d4e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xfffeb36e6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaad51a8f9c4 in timer_new_full qemu/include/qemu/timer.h:523 qemu#3 0xaaad51a8f9c4 in timer_new qemu/include/qemu/timer.h:544 qemu#4 0xaaad51a8f9c4 in timer_new_ns qemu/include/qemu/timer.h:562 qemu#5 0xaaad51a8f9c4 in s390_cpu_initfn qemu/target/s390x/cpu.c:304 qemu#6 0xaaad51e00f58 in object_init_with_type qemu/qom/object.c:371 qemu#7 0xaaad51e0406c in object_initialize_with_type qemu/qom/object.c:515 qemu#8 0xaaad51e042e0 in object_new_with_type qemu/qom/object.c:729 qemu#9 0xaaad51e3ff40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 qemu#10 0xaaad51910518 in qdev_device_help qemu/softmmu/qdev-monitor.c:283 qemu#11 0xaaad51911918 in qmp_device_add qemu/softmmu/qdev-monitor.c:801 qemu#12 0xaaad51911e48 in hmp_device_add qemu/softmmu/qdev-monitor.c:916 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20201204081209.360524-4-ganqixin@huawei.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>

Providing the 'if' property, but not 'canbus' segfaults like this: #0 0x0000555555b0f14d in can_bus_insert_client (bus=0x0, client=0x555556aa9af0) at ../net/can/can_core.c:88 #1 0x00005555559c3803 in can_host_connect (ch=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:62 #2 0x00005555559c386a in can_host_complete (uc=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:72 qemu#3 0x0000555555d52de9 in user_creatable_complete (uc=0x555556aa9ac0, errp=0x7fffffffd5c8) at ../qom/object_interfaces.c:23 Add the missing NULL check. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201130105615.21799-5-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

When running qom-test, a memory leak occurred in the ppce500_init function, this patch free irqs array to fix it. ASAN shows memory leak stack: Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0xfffc5ceee1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xfffc5c806800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaacf9999244 in ppce500_init qemu/hw/ppc/e500.c:859 qemu#3 0xaaacf97434e8 in machine_run_board_init qemu/hw/core/machine.c:1134 qemu#4 0xaaacf9c9475c in qemu_init qemu/softmmu/vl.c:4369 qemu#5 0xaaacf94785a0 in main qemu/softmmu/main.c:49 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Message-Id: <20201204075822.359832-1-ganqixin@huawei.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

In host_memory_backend_get_host_nodes, we build host_nodes list and output it to v (a StringOutputVisitor) but forget to free the list. This fixes the memory leak. The memory leak stack: Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0xfffda30b3393 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xd3393) #1 0xfffda1d28b9b in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x58b9b) #2 0xaaab05ca6e43 in host_memory_backend_get_host_nodes backends/hostmem.c:94 qemu#3 0xaaab061ddf83 in object_property_get_uint16List qom/object.c:1478 qemu#4 0xaaab05866513 in query_memdev hw/core/machine-qmp-cmds.c:312 qemu#5 0xaaab061d980b in do_object_child_foreach qom/object.c:1001 qemu#6 0xaaab0586779b in qmp_query_memdev hw/core/machine-qmp-cmds.c:328 qemu#7 0xaaab0615ed3f in qmp_marshal_query_memdev qapi/qapi-commands-machine.c:327 qemu#8 0xaaab0632d647 in do_qmp_dispatch qapi/qmp-dispatch.c:147 qemu#9 0xaaab0632d647 in qmp_dispatch qapi/qmp-dispatch.c:190 qemu#10 0xaaab0610f74b in monitor_qmp_dispatch monitor/qmp.c:120 qemu#11 0xaaab0611074b in monitor_qmp_bh_dispatcher monitor/qmp.c:209 qemu#12 0xaaab063caefb in aio_bh_poll util/async.c:117 qemu#13 0xaaab063d30fb in aio_dispatch util/aio-posix.c:459 qemu#14 0xaaab063cac8f in aio_ctx_dispatch util/async.c:268 qemu#15 0xfffda1d22a6b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a6b) qemu#16 0xaaab063d0e97 in glib_pollfds_poll util/main-loop.c:218 qemu#17 0xaaab063d0e97 in os_host_main_loop_wait util/main-loop.c:241 qemu#18 0xaaab063d0e97 in main_loop_wait util/main-loop.c:517 qemu#19 0xaaab05c8bfa7 in main_loop /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:1791 qemu#20 0xaaab05713bc3 in main /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:4473 qemu#21 0xfffda0a83ebf in __libc_start_main (/usr/lib64/libc.so.6+0x23ebf) qemu#22 0xaaab0571ed5f (aarch64-softmmu/qemu-system-aarch64+0x88ed5f) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). Fixes: 4cf1b76 (hostmem: add properties for NUMA memory policy) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Tested-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20201210075226.20196-1-zhukeqian1@huawei.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

…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 qemu#3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…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 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278 qemu#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49 qemu#11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…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 qemu#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 qemu#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 qemu#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 qemu#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…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 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401 qemu#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 qemu#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862 qemu#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283 qemu#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…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 qemu#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 qemu#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 qemu#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 qemu#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 qemu#3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42) qemu#4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20210106050625.518041-1-ganqixin@huawei.com> Signed-off-by: Thomas Huth <thuth@redhat.com>

When the slot is in steady powered-off state and the device is being removed, there's no need to press the attention button. Nor is it mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0. Moreover it confuses the guest, Linux in particular, as it assumes that the attention button pressed in this state indicates that the device has been inserted and will need to be powered on. Therefore it transitions the slot into BLINKING_ON state for 5 seconds, and discovers at the end that no device is actually inserted: ... unplug request [12685.451329] shpchp 0000:01:00.0: Button pressed on Slot(2) [12685.455478] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press ... in 5 seconds OS powers off the slot, QEMU ejects the device [12690.632282] shpchp 0000:01:00.0: Latch open on Slot(2) ... excessive button press in steady powered-off state [12690.634267] shpchp 0000:01:00.0: Button pressed on Slot(2) [12690.636256] shpchp 0000:01:00.0: Card not present on Slot(2) ... the last button press spawns powering on the slot [12690.638909] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press ... in 5 more seconds attempt to power on discovers empty slot [12695.735986] shpchp 0000:01:00.0: No adapter on slot(2) Worse, if the real device insertion happens within 5 seconds from the apparent completion of the previous device removal (signaled via DEVICE_DELETED event), the new button press will be interpreted as the cancellation of that misguided powering on: [13448.965295] shpchp 0000:01:00.0: Button pressed on Slot(2) [13448.969430] shpchp 0000:01:00.0: PCI slot #2 - powering off due to button press [13454.025107] shpchp 0000:01:00.0: Latch open on Slot(2) [13454.027101] shpchp 0000:01:00.0: Button pressed on Slot(2) [13454.029165] shpchp 0000:01:00.0: Card not present on Slot(2) ... the excessive button press spawns powering on the slot ... device has already been ejected by QEMU [13454.031949] shpchp 0000:01:00.0: PCI slot #2 - powering on due to button press ... new device is inserted in the slot [13456.861545] shpchp 0000:01:00.0: Latch close on Slot(2) ... valid button press arrives before 5 s since the wrong one [13456.864894] shpchp 0000:01:00.0: Button pressed on Slot(2) [13456.869211] shpchp 0000:01:00.0: Card present on Slot(2) ... the valid button press is counted as cancellation of the wrong one [13456.873173] shpchp 0000:01:00.0: Button cancel on Slot(2) [13456.877101] shpchp 0000:01:00.0: PCI slot #2 - action canceled due to button press As a result, the newly inserted device isn't brought up by the guest. Avoid this situation by not pushing the attention button when the device in the slot is in powered-off state and is being ejected. FWIW pcie implementation doesn't suffer from this problem. Signed-off-by: Roman Kagan <rvkagan@yandex-team.ru> Message-Id: <20201102053750.2281818-1-rvkagan@yandex-team.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

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 qemu#3 0xaaabf5621cfc in timer_new qemu/include/qemu/timer.h:544 qemu#4 0xaaabf5621cfc in timer_new_ns qemu/include/qemu/timer.h:562 qemu#5 0xaaabf5621cfc in pl031_init qemu/hw/rtc/pl031.c:194 qemu#6 0xaaabf6339f6c in object_initialize_with_type qemu/qom/object.c:515 qemu#7 0xaaabf633a1e0 in object_new_with_type qemu/qom/object.c:729 qemu#8 0xaaabf6375e40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 qemu#9 0xaaabf5a95540 in qdev_device_help qemu/softmmu/qdev-monitor.c:283 qemu#10 0xaaabf5a96940 in qmp_device_add qemu/softmmu/qdev-monitor.c:801 qemu#11 0xaaabf5a96e70 in hmp_device_add qemu/softmmu/qdev-monitor.c:916 qemu#12 0xaaabf5ac0a2c in handle_hmp_command qemu/monitor/hmp.c:1100 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210112112705.380534-2-ganqixin@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>

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 qemu#3 0xaaae50303d0c in timer_new qemu/include/qemu/timer.h:544 qemu#4 0xaaae50303d0c in timer_new_ns qemu/include/qemu/timer.h:562 qemu#5 0xaaae50303d0c in mos6522_init qemu/hw/misc/mos6522.c:490 qemu#6 0xaaae50b77d70 in object_init_with_type qemu/qom/object.c:371 qemu#7 0xaaae50b7ae84 in object_initialize_with_type qemu/qom/object.c:515 qemu#8 0xaaae50b7b0f8 in object_new_with_type qemu/qom/object.c:729 qemu#9 0xaaae50bb6d58 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 qemu#10 0xaaae50d7e1dc in qmp_marshal_device_list_properties qemu/qapi/qapi-commands-qdev.c:59 qemu#11 0xaaae50dc87a0 in do_qmp_dispatch_bh qemu/qapi/qmp-dispatch.c:110 qemu#12 0xaaae50d931a0 in aio_bh_call qemu/util/async.c:136 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20210112112705.380534-3-ganqixin@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>

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 qemu#3 0x55b1bec09699 in parse_object ../qobject/json-parser.c:318 qemu#4 0x55b1bec0b2df in parse_value ../qobject/json-parser.c:546 qemu#5 0x55b1bec0b6a9 in json_parser_parse ../qobject/json-parser.c:580 qemu#6 0x55b1bec060d1 in json_message_process_token ../qobject/json-streamer.c:92 qemu#7 0x55b1bec16a12 in json_lexer_feed_char ../qobject/json-lexer.c:313 qemu#8 0x55b1bec16fbd in json_lexer_feed ../qobject/json-lexer.c:350 qemu#9 0x55b1bec06453 in json_message_parser_feed ../qobject/json-streamer.c:121 qemu#10 0x55b1bebc2d51 in qmp_fd_receive ../tests/qtest/libqtest.c:614 qemu#11 0x55b1bebc2f5e in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636 qemu#12 0x55b1bebc2e6c in qtest_qmp_receive ../tests/qtest/libqtest.c:624 qemu#13 0x55b1bebc3340 in qtest_vqmp ../tests/qtest/libqtest.c:715 qemu#14 0x55b1bebc3942 in qtest_qmp ../tests/qtest/libqtest.c:756 qemu#15 0x55b1bebbd64a in adc_qom_set ../tests/qtest/npcm7xx_adc-test.c:127 qemu#16 0x55b1bebbd793 in adc_write_input ../tests/qtest/npcm7xx_adc-test.c:140 qemu#17 0x55b1bebbdf92 in test_convert_external ../tests/qtest/npcm7xx_adc-test.c:246 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Message-id: 20210118065627.79903-1-ganqixin@huawei.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 qemu#3 0x556313115bca in parse_object ../qobject/json-parser.c:318 qemu#4 0x556313117810 in parse_value ../qobject/json-parser.c:546 qemu#5 0x556313117bda in json_parser_parse ../qobject/json-parser.c:580 qemu#6 0x55631310fe67 in json_message_process_token ../qobject/json-streamer.c:92 qemu#7 0x5563131210b7 in json_lexer_feed_char ../qobject/json-lexer.c:313 qemu#8 0x556313121662 in json_lexer_feed ../qobject/json-lexer.c:350 qemu#9 0x5563131101e9 in json_message_parser_feed ../qobject/json-streamer.c:121 qemu#10 0x5563130cb81e in qmp_fd_receive ../tests/qtest/libqtest.c:614 qemu#11 0x5563130cba2b in qtest_qmp_receive_dict ../tests/qtest/libqtest.c:636 qemu#12 0x5563130cb939 in qtest_qmp_receive ../tests/qtest/libqtest.c:624 qemu#13 0x5563130cbe0d in qtest_vqmp ../tests/qtest/libqtest.c:715 qemu#14 0x5563130cc40f in qtest_qmp ../tests/qtest/libqtest.c:756 qemu#15 0x5563130c5623 in pwm_qom_get ../tests/qtest/npcm7xx_pwm-test.c:180 qemu#16 0x5563130c595e in pwm_get_duty ../tests/qtest/npcm7xx_pwm-test.c:210 qemu#17 0x5563130c7529 in test_toggle ../tests/qtest/npcm7xx_pwm-test.c:447 Reported-by: Euler Robot <euler.robot@huawei.com> Message-Id: <20210115075634.717909-1-ganqixin@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Thomas Huth <thuth@redhat.com>

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 qemu#3 0x556b3b588f61 in parse_value /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:546:16 qemu#4 0x556b3b5886e8 in json_parser_parse /home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:580:14 qemu#5 0x556b3b52ff4a in json_message_process_token /home/stefanb/tmp/qemu-tip/build/../qobject/json-streamer.c:92:12 qemu#6 0x556b3b59896f in json_lexer_feed_char /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:313:13 qemu#7 0x556b3b598443 in json_lexer_feed /home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:350:9 qemu#8 0x556b3b436c70 in qmp_fd_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:614:9 qemu#9 0x556b3b435871 in qtest_qmp_receive_dict /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:636:12 qemu#10 0x556b3b435871 in qtest_qmp_receive /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:624:27 qemu#11 0x556b3b435c59 in qtest_vqmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:715:12 qemu#12 0x556b3b435c59 in qtest_qmp /home/stefanb/tmp/qemu-tip/build/../tests/qtest/libqtest.c:756:16 qemu#13 0x556b3b4328c7 in tpm_util_wait_for_migration_complete /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-util.c:245:15 qemu#14 0x556b3b4333be in tpm_test_swtpm_migration_test /home/stefanb/tmp/qemu-tip/build/../tests/qtest/tpm-tests.c:117:5 qemu#15 0x152b0e98e29d (/lib64/libglib-2.0.so.0+0x7b29d) Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20210115204637.3332555-1-stefanb@linux.vnet.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>

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 <JPEWhacker@gmail.com> Message-Id: <20210112210239.28836-1-JPEWhacker@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

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 qemu#3 0x56187adc573b in memory_region_read_with_attrs_accessor softmmu/memory.c:464:9 qemu#4 0x56187ad7903a in access_with_adjusted_size softmmu/memory.c:552:18 qemu#5 0x56187ad766d6 in memory_region_dispatch_read1 softmmu/memory.c:1426:16 qemu#6 0x56187ad758a8 in memory_region_dispatch_read softmmu/memory.c:1449:9 qemu#7 0x56187b09e84c in flatview_read_continue softmmu/physmem.c:2822:23 qemu#8 0x56187b0a0115 in flatview_read softmmu/physmem.c:2862:12 qemu#9 0x56187b09fc9e in address_space_read_full softmmu/physmem.c:2875:18 qemu#10 0x56187aa88633 in address_space_read include/exec/memory.h:2489:18 qemu#11 0x56187aa88633 in qtest_process_command softmmu/qtest.c:558:13 qemu#12 0x56187aa81881 in qtest_process_inbuf softmmu/qtest.c:797:9 qemu#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 <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Message-id: 20210128161417.3726358-1-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

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 qemu#3 0x0000561803530633 in aio_bh_call (bh=0x7f60d40a7e80) at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:136 qemu#4 aio_bh_poll (ctx=ctx@entry=0x5618056c7580) at /build/qemu-6MF7tq/qemu-5.0.1/util/async.c:164 qemu#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 qemu#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 qemu#7 0x000056180345c50a in bdrv_attach_aio_context (new_context=0x5618056c7580, bs=0x561805ed4c00) at /build/qemu-6MF7tq/qemu-5.0.1/block.c:6172 qemu#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 qemu#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 qemu#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 qemu#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 qemu#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 qemu#13 0x00005618033d67bf in virtio_bus_stop_ioeventfd (bus=0x5618056d9f08) at /build/qemu-6MF7tq/qemu-5.0.1/hw/virtio/virtio-bus.c:245 qemu#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 qemu#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 qemu#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 qemu#17 0x00005618033e3765 in migration_completion (s=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:2914 qemu#18 migration_iteration_run (s=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3275 qemu#19 migration_thread (opaque=opaque@entry=0x5618056e6960) at /build/qemu-6MF7tq/qemu-5.0.1/migration/migration.c:3439 qemu#20 0x0000561803536ad6 in qemu_thread_start (args=<optimized out>) at /build/qemu-6MF7tq/qemu-5.0.1/util/qemu-thread-posix.c:519 qemu#21 0x00007f61085d06ba in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 qemu#22 0x00007f610830641d in sysctl () from /lib/x86_64-linux-gnu/libc.so.6 qemu#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 <rvkagan@yandex-team.ru> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210129073859.683063-2-rvkagan@yandex-team.ru> Signed-off-by: Eric Blake <eblake@redhat.com>

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 qemu#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 qemu#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 qemu#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 qemu#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 qemu#7 0x0000562a241fc7bf in virtio_bus_stop_ioeventfd (bus=0x562a260dbf08) at /build/qemu-gYtjVn/qemu-5.0.1/hw/virtio/virtio-bus.c:245 qemu#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 qemu#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 qemu#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 qemu#11 0x0000562a24209765 in migration_completion (s=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:2914 qemu#12 migration_iteration_run (s=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3275 qemu#13 migration_thread (opaque=opaque@entry=0x562a260e83a0) at /build/qemu-gYtjVn/qemu-5.0.1/migration/migration.c:3439 qemu#14 0x0000562a2435ca96 in qemu_thread_start (args=<optimized out>) at /build/qemu-gYtjVn/qemu-5.0.1/util/qemu-thread-posix.c:519 qemu#15 0x00007feed31466ba in start_thread (arg=0x7feeadc9c700) at pthread_create.c:333 qemu#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 qemu#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 <rvkagan@yandex-team.ru> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210129073859.683063-3-rvkagan@yandex-team.ru> Signed-off-by: Eric Blake <eblake@redhat.com>

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 qemu#3 object_unref (objptr=0x555557de5120) at ../qom/object.c:1184 qemu#4 0x0000555555b4de9d in bus_free_bus_child (kid=0x555557df0660) at ../hw/core/qdev.c:55 qemu#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 qemu#3 0x0000555555b6fa17 in object_property_del_child ( child=0x555557de5120, obj=0x555557ddcf90) at ../qom/object.c:645 qemu#4 object_unparent (obj=0x555557de5120) at ../qom/object.c:664 qemu#5 0x0000555555b4c071 in bus_unparent (obj=<optimized out>) at ../hw/core/bus.c:147 qemu#6 0x0000555555b70465 in object_finalize_child_property ( obj=<optimized out>, name=<optimized out>, opaque=0x555557de5098) at ../qom/object.c:1725 qemu#7 0x0000555555b6fa17 in object_property_del_child ( child=0x555557de5098, obj=0x555557ddcf90) at ../qom/object.c:645 qemu#8 object_unparent (obj=0x555557de5098) at ../qom/object.c:664 qemu#9 0x0000555555b4ee19 in device_unparent (obj=<optimized out>) at ../hw/core/qdev.c:981 qemu#10 0x0000555555b70465 in object_finalize_child_property ( obj=<optimized out>, name=<optimized out>, opaque=0x555557ddcf90) at ../qom/object.c:1725 qemu#11 0x0000555555b6fa17 in object_property_del_child ( child=0x555557ddcf90, obj=0x55555685da10) at ../qom/object.c:645 qemu#12 object_unparent (obj=0x555557ddcf90) at ../qom/object.c:664 qemu#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 qemu#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 qemu#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 qemu#5 0x0000555555b71044 in object_property_set_bool ( obj=0x555557ddcf90, name=0x555555db99df "realized", value=<optimized out>, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 qemu#6 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>, dev=0x555557ddcf90, opaque=<optimized out>) at /home/qemu/include/hw/qdev-core.h:17 qemu#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 qemu#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 qemu#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 qemu#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 qemu#6 0x0000555555b4edc5 in qdev_unrealize (dev=<optimized out>) at ../hw/core/qdev.c:403 qemu#7 0x0000555555b4c2a9 in bus_set_realized (obj=<optimized out>, value=<optimized out>, errp=<optimized out>) at ../hw/core/bus.c:204 qemu#8 0x0000555555b6eab6 in property_set_bool (obj=0x555557de5098, v=<optimized out>, name=<optimized out>, opaque=0x555557df04c0, errp=0x7fffee28e0a0) at ../qom/object.c:2255 qemu#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 qemu#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 qemu#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 qemu#12 0x0000555555b4c725 in qbus_unrealize ( bus=bus@entry=0x555557de5098) at ../hw/core/bus.c:178 qemu#13 0x0000555555b4fc00 in device_set_realized (obj=0x555557ddcf90, value=<optimized out>, errp=0x7fffee28e1e0) at ../hw/core/qdev.c:844 qemu#14 0x0000555555b6eab6 in property_set_bool (obj=0x555557ddcf90, v=<optimized out>, name=<optimized out>, opaque=0x555556650ba0, errp=0x7fffee28e1e0) at ../qom/object.c:2255 qemu#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 qemu#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 qemu#17 0x0000555555b71054 in object_property_set_bool ( obj=0x555557ddcf90, name=0x555555db99ff "realized", value=<optimized out>, errp=0x5555565bbf38 <error_abort>) at ../qom/object.c:1470 qemu#18 0x0000555555921cb7 in pcie_unplug_device (bus=<optimized out>, dev=0x555557ddcf90, opaque=<optimized out>) at /home/qemu/include/hw/qdev-core.h:17 qemu#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 <eperezma@redhat.com> Message-Id: <20210125192505.390554-1-eperezma@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

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 qemu#3 0x0000559fffeded7b in slave_read (opaque=0x55a0012f6680) at ../hw/virtio/vhost-user.c:1464 qemu#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 <eperezma@redhat.com> Message-Id: <20210129090728.831208-1-eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

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 qemu#3 0x0000555d12f95b4c in st_flush_trace_buffer () at ../trace/simple.c:383 qemu#4 0x00007f9dac5e43a7 in __run_exit_handlers () at /lib64/libc.so.6 qemu#5 0x00007f9dac5e4550 in on_exit () at /lib64/libc.so.6 qemu#6 0x0000555d12d454de in os_daemonize () at ../os-posix.c:255 qemu#7 0x0000555d12d0bd5c in qemu_maybe_daemonize (pid_file=0x0) at ../softmmu/vl.c:2408 qemu#8 0x0000555d12d0e566 in qemu_init (argc=8, argv=0x7fffc594d9b8, envp=0x7fffc594da00) at ../softmmu/vl.c:3459 qemu#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 <pbonzini@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210105181437.538366-2-danielhb413@gmail.com> Acked-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Running the WDR opcode triggers a segfault: $ cat > foo.S << EOF > __start: > wdr > EOF $ avr-gcc -nostdlib -nostartfiles -mmcu=avr6 foo.S -o foo.elf $ qemu-system-avr -serial mon:stdio -nographic -no-reboot \ -M mega -bios foo.elf -d in_asm --singlestep IN: 0x00000000: WDR Segmentation fault (core dumped) (gdb) bt #0 0x00005555add0b23a in gdb_get_cpu_pid (cpu=0x5555af5a4af0) at ../gdbstub.c:718 #1 0x00005555add0b2dd in gdb_get_cpu_process (cpu=0x5555af5a4af0) at ../gdbstub.c:743 #2 0x00005555add0e477 in gdb_set_stop_cpu (cpu=0x5555af5a4af0) at ../gdbstub.c:2742 qemu#3 0x00005555adc99b96 in cpu_handle_guest_debug (cpu=0x5555af5a4af0) at ../softmmu/cpus.c:306 qemu#4 0x00005555adcc66ab in rr_cpu_thread_fn (arg=0x5555af5a4af0) at ../accel/tcg/tcg-accel-ops-rr.c:224 qemu#5 0x00005555adefaf12 in qemu_thread_start (args=0x5555af5d9870) at ../util/qemu-thread-posix.c:521 qemu#6 0x00007f692d940ea5 in start_thread () from /lib64/libpthread.so.0 qemu#7 0x00007f692d6699fd in clone () from /lib64/libc.so.6 Since the watchdog peripheral is not implemented, simply log the opcode as unimplemented and keep going. Reported-by: Fred Konrad <konrad@adacore.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com> Message-Id: <20210502190900.604292-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>

This is a partial revert of commits 77542d4 and bc79c87. Usually, an error during initialisation means that the configuration was wrong. Reconnecting won't make the error go away, but just turn the error condition into an endless loop. Avoid this and return errors again. Additionally, calling vhost_user_blk_disconnect() from the chardev event handler could result in use-after-free because none of the initialisation code expects that the device could just go away in the middle. So removing the call fixes crashes in several places. For example, using a num-queues setting that is incompatible with the backend would result in a crash like this (dereferencing dev->opaque, which is already NULL): #0 0x0000555555d0a4bd in vhost_user_read_cb (source=0x5555568f4690, condition=(G_IO_IN | G_IO_HUP), opaque=0x7fffffffcbf0) at ../hw/virtio/vhost-user.c:313 #1 0x0000555555d950d3 in qio_channel_fd_source_dispatch (source=0x555557c3f750, callback=0x555555d0a478 <vhost_user_read_cb>, user_data=0x7fffffffcbf0) at ../io/channel-watch.c:84 #2 0x00007ffff7b32a9f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 qemu#3 0x00007ffff7b84a98 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0 qemu#4 0x00007ffff7b32163 in g_main_loop_run () at /lib64/libglib-2.0.so.0 qemu#5 0x0000555555d0a724 in vhost_user_read (dev=0x555557bc62f8, msg=0x7fffffffcc50) at ../hw/virtio/vhost-user.c:402 qemu#6 0x0000555555d0ee6b in vhost_user_get_config (dev=0x555557bc62f8, config=0x555557bc62ac "", config_len=60) at ../hw/virtio/vhost-user.c:2133 qemu#7 0x0000555555d56d46 in vhost_dev_get_config (hdev=0x555557bc62f8, config=0x555557bc62ac "", config_len=60) at ../hw/virtio/vhost.c:1566 qemu#8 0x0000555555cdd150 in vhost_user_blk_device_realize (dev=0x555557bc60b0, errp=0x7fffffffcf90) at ../hw/block/vhost-user-blk.c:510 qemu#9 0x0000555555d08f6d in virtio_device_realize (dev=0x555557bc60b0, errp=0x7fffffffcff0) at ../hw/virtio/virtio.c:3660 Note that this removes the ability to reconnect during initialisation (but not during operation) when there is no permanent error, but the backend restarts, as the implementation was buggy. This feature can be added back in a follow-up series after changing error paths to distinguish cases where retrying could help from cases with permanent errors. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210429171316.162022-3-kwolf@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

…accept destination side: $ build/qemu-system-x86_64 -enable-kvm -netdev tap,id=hn0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -device e1000,netdev=hn0,mac=50:52:54:00:11:22 -boot c -drive if=none,file=./Fedora-rdma-server-migration.qcow2,id=drive-virtio-disk0 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -m 2048 -smp 2 -device piix3-usb-uhci -device usb-tablet -monitor stdio -vga qxl -spice streaming-video=filter,port=5902,disable-ticketing -incoming rdma:192.168.1.10:8888 (qemu) migrate_set_capability postcopy-ram on (qemu) dest_init RDMA Device opened: kernel name rocep1s0f0 uverbs device name uverbs0, infiniband_verbs class device path /sys/class/infiniband_verbs/uverbs0, infiniband class device path /sys/class/infiniband/rocep1s0f0, transport: (2) Ethernet Segmentation fault (core dumped) (gdb) bt #0 qemu_rdma_accept (rdma=0x0) at ../migration/rdma.c:3272 #1 rdma_accept_incoming_migration (opaque=0x0) at ../migration/rdma.c:3986 #2 0x0000563c9e51f02a in aio_dispatch_handler (ctx=ctx@entry=0x563ca0606010, node=0x563ca12b2150) at ../util/aio-posix.c:329 qemu#3 0x0000563c9e51f752 in aio_dispatch_handlers (ctx=0x563ca0606010) at ../util/aio-posix.c:372 qemu#4 aio_dispatch (ctx=0x563ca0606010) at ../util/aio-posix.c:382 qemu#5 0x0000563c9e4f4d9e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../util/async.c:306 qemu#6 0x00007fe96ef3fa9f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 qemu#7 0x0000563c9e4ffeb8 in glib_pollfds_poll () at ../util/main-loop.c:231 qemu#8 os_host_main_loop_wait (timeout=12188789) at ../util/main-loop.c:254 qemu#9 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:530 qemu#10 0x0000563c9e3c7211 in qemu_main_loop () at ../softmmu/runstate.c:725 qemu#11 0x0000563c9dfd46fe in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:50 The rdma return path will not be created when qemu incoming is starting since migrate_copy() is false at that moment, then a NULL return path rdma was referenced if the user enabled postcopy later. Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Message-Id: <20210525080552.28259-3-lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

…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 qemu#3 0x0000555555950f7d in migration_channel_connect (...) error@entry=0x0) at .../migration/channel.c:107 qemu#4 0x0000555555910922 in exec_start_outgoing_migration (...) at .../migration/exec.c:42 Reported-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>

blk_get_geometry() eventually calls bdrv_nb_sectors(), which is a co_wrapper_mixed_bdrv_rdlock. This means that when it is called from coroutine context, it already assume to have the graph locked. However, virtio_blk_sect_range_ok() in block/export/virtio-blk-handler.c (used by vhost-user-blk and VDUSE exports) runs in a coroutine, but doesn't take the graph lock - blk_*() functions are generally expected to do that internally. This causes an assertion failure when accessing an export for the first time if it runs in an iothread. This is an example of the crash: $ ./storage-daemon/qemu-storage-daemon --object iothread,id=th0 --blockdev file,filename=/home/kwolf/images/hd.img,node-name=disk --export vhost-user-blk,addr.type=unix,addr.path=/tmp/vhost.sock,node-name=disk,id=exp0,iothread=th0 qemu-storage-daemon: ../block/graph-lock.c:268: void assert_bdrv_graph_readable(void): Assertion `qemu_in_main_thread() || reader_count()' failed. (gdb) bt #0 0x00007ffff6eafe5c in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x00007ffff6e5fa76 in raise () from /lib64/libc.so.6 #2 0x00007ffff6e497fc in abort () from /lib64/libc.so.6 qemu#3 0x00007ffff6e4971b in __assert_fail_base.cold () from /lib64/libc.so.6 qemu#4 0x00007ffff6e58656 in __assert_fail () from /lib64/libc.so.6 qemu#5 0x00005555556337a3 in assert_bdrv_graph_readable () at ../block/graph-lock.c:268 qemu#6 0x00005555555fd5a2 in bdrv_co_nb_sectors (bs=0x5555564c5ef0) at ../block.c:5847 qemu#7 0x00005555555ee949 in bdrv_nb_sectors (bs=0x5555564c5ef0) at block/block-gen.c:256 qemu#8 0x00005555555fd6b9 in bdrv_get_geometry (bs=0x5555564c5ef0, nb_sectors_ptr=0x7fffef7fedd0) at ../block.c:5884 qemu#9 0x000055555562ad6d in blk_get_geometry (blk=0x5555564cb200, nb_sectors_ptr=0x7fffef7fedd0) at ../block/block-backend.c:1624 qemu#10 0x00005555555ddb74 in virtio_blk_sect_range_ok (blk=0x5555564cb200, block_size=512, sector=0, size=512) at ../block/export/virtio-blk-handler.c:44 qemu#11 0x00005555555dd80d in virtio_blk_process_req (handler=0x5555564cbb98, in_iov=0x7fffe8003830, out_iov=0x7fffe8003860, in_num=1, out_num=0) at ../block/export/virtio-blk-handler.c:189 qemu#12 0x00005555555dd546 in vu_blk_virtio_process_req (opaque=0x7fffe8003800) at ../block/export/vhost-user-blk-server.c:66 qemu#13 0x00005555557bf4a1 in coroutine_trampoline (i0=-402635264, i1=32767) at ../util/coroutine-ucontext.c:177 qemu#14 0x00007ffff6e75c20 in ?? () from /lib64/libc.so.6 qemu#15 0x00007fffefffa870 in ?? () qemu#16 0x0000000000000000 in ?? () Fix this by creating a new blk_co_get_geometry() that takes the lock, and changing blk_get_geometry() to be a co_wrapper_mixed around it. To make the resulting code cleaner, virtio-blk-handler.c can directly call the coroutine version now (though that wouldn't be necessary for fixing the bug, taking the lock in blk_co_get_geometry() is what fixes it). Fixes: 8ab8140 Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230327113959.60071-1-kwolf@redhat.com> Reviewed-by: Emanuele Giuseppe Esposito <eesposit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

stsquad and others added 24 commits January 14, 2020 15:03

gdbstub: add helper for 128 bit registers

663f2cd

Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> --- v2 - take care of endianess of the whole 128 bit word

target/arm: prepare for multiple dynamic XMLs

a397820

We will want to generate similar dynamic XML for gdbstub support of SVE registers (the upstream doesn't use XML). To that end lightly rename a few things to make the distinction. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

tests/tcg: add a configure compiler check for ARMv8.1 and SVE

0fe1452

We will need this for some tests later. The docker images already support it by default. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

configure: allow user to specify what gdb to use

3350d29

This is useful, especially when testing relatively new gdbstub features that might not be in distro packages yet. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

tests/guest-debug: add a simple test runner

f2e0e97

The test runners job is to start QEMU with guest debug enabled and then spawn a gdb process running a test script that exercises the functionality it wants to test. Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Testing/docker binfmt tweaks #2

Testing/docker binfmt tweaks #2

stsquad commented Jan 21, 2020

Testing/docker binfmt tweaks #2

Testing/docker binfmt tweaks #2

Conversation

stsquad commented Jan 21, 2020