summary refs log tree commit diff stats
path: root/scripts/qapi/expr.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2022-02-16block: print the server key type and fingerprint on failureDaniel P. Berrangé1-7/+30
When validating the server key fingerprint fails, it is difficult for the user to know what they got wrong. The fingerprint accepted by QEMU is received in a different format than OpenSSH displays. There can also be keys for multiple different ciphers in known_hosts. It may not be obvious which cipher QEMU will use and whether it will be the same as OpenSSH. Address this by printing the server key type and its corresponding fingerprint in the format QEMU accepts. Reviewed-by: Hanna Reitz <hreitz@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-16block: support sha256 fingerprint with pre-blockdev optionsDaniel P. Berrangé1-0/+5
When support for sha256 fingerprint checking was aded in commit bf783261f0aee6e81af3916bff7606d71ccdc153 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Tue Jun 22 12:51:56 2021 +0100 block/ssh: add support for sha256 host key fingerprints it was only made to work with -blockdev. Getting it working with -drive requires some extra custom parsing. Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-16block: better document SSH host key fingerprint checkingDaniel P. Berrangé1-4/+26
The docs still illustrate host key fingerprint checking using the old md5 hashes which are considered insecure and obsolete. Change it to illustrate using a sha256 hash. Also show how to extract the hash value from the known_hosts file. Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-14util: adjust coroutine pool size to virtio block queueHiroki Narukawa3-4/+31
Coroutine pool size was 64 from long ago, and the basis was organized in the commit message in 4d68e86b. At that time, virtio-blk queue-size and num-queue were not configuable, and equivalent values were 128 and 1. Coroutine pool size 64 was fine then. Later queue-size and num-queue got configuable, and default values were increased. Coroutine pool with size 64 exhausts frequently with random disk IO in new size, and slows down. This commit adjusts coroutine pool size adaptively with new values. This commit adds 64 by default, but now coroutine is not only for block devices, and is not too much burdon comparing with new default. pool size of 128 * vCPUs. Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp> Message-id: 20220214115302.13294-2-hnarukaw@yahoo-corp.jp Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-02-14Deprecate C virtiofsdDr. David Alan Gilbert1-0/+17
There's a nice new Rust implementation out there; recommend people do new work on that. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20220210174714.19843-1-dgilbert@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-02-14tools/virtiofsd: Add rseq syscall to the seccomp allowlistChristian Ehrhardt1-0/+3
The virtiofsd currently crashes when used with glibc 2.35. That is due to the rseq system call being added to every thread creation [1][2]. [1]: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/ [2]: https://sourceware.org/pipermail/libc-alpha/2022-February/136040.html This happens not at daemon start, but when a guest connects /usr/lib/qemu/virtiofsd -f --socket-path=/tmp/testvfsd -o sandbox=chroot \ -o source=/var/guests/j-virtiofs --socket-group=kvm virtio_session_mount: Waiting for vhost-user socket connection... # start ok, now guest will connect virtio_session_mount: Received vhost-user socket connection virtio_loop: Entry fv_queue_set_started: qidx=0 started=1 fv_queue_set_started: qidx=1 started=1 Bad system call (core dumped) We have to put rseq on the seccomp allowlist to avoid that the daemon is crashing in this case. Reported-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-id: 20220209111456.3328420-1-christian.ehrhardt@canonical.com [Moved rseq to its alphabetically ordered position in the seccomp allowlist. --Stefan] Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2022-02-14hw/nvme: add support for zoned random write areaKlaus Jensen5-20/+237
Add support for TP 4076 ("Zoned Random Write Area"), v2021.08.23 ("Ratified"). This adds three new namespace parameters: "zoned.numzrwa" (number of zrwa resources, i.e. number of zones that can have a zrwa), "zoned.zrwas" (zrwa size in LBAs), "zoned.zrwafg" (granularity in LBAs for flushes). Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14hw/nvme: add ozcs enumKlaus Jensen2-1/+6
Add enumeration for OZCS values. Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14hw/nvme: add struct for zone management sendKlaus Jensen2-6/+23
Add struct for Zone Management Send in preparation for more zone send flags. Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14hw/nvme/ctrl: Pass buffers as 'void *' typesPhilippe Mathieu-Daudé2-7/+7
These buffers can be anything, not an array of chars, so use the 'void *' type for them. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14hw/nvme/ctrl: Have nvme_addr_write() take const bufferPhilippe Mathieu-Daudé1-1/+1
The 'buf' argument is not modified, so better pass it as const type. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14hw/nvme: fix CVE-2021-3929Klaus Jensen1-0/+22
This fixes CVE-2021-3929 "locally" by denying DMA to the iomem of the device itself. This still allows DMA to MMIO regions of other devices (e.g. doing P2P DMA to the controller memory buffer of another NVMe device). Fixes: CVE-2021-3929 Reported-by: Qiuhao Li <Qiuhao.Li@outlook.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
2022-02-14net/eth: Don't consider ESP to be an IPv6 option headerThomas Jansen1-1/+0
The IPv6 option headers all have in common that they start with some common fields, in particular the type of the next header followed by the extention header length. This is used to traverse the list of the options. The ESP header does not follow that format, which can break the IPv6 option header traversal code in eth_parse_ipv6_hdr(). The effect of that is that network interfaces such as vmxnet3 that use the following call chain eth_is_ip6_extension_header_type eth_parse_ipv6_hdr net_tx_pkt_parse_headers net_tx_pkt_parse vmxnet3_process_tx_queue to send packets from the VM out to the host will drop packets of the following structure: Ethernet-Header(IPv6-Header(ESP(encrypted data))) Note that not all types of network interfaces use the net_tx_pkt_parse function though, leading to inconsistent behavior regarding sending those packets. The e1000 network interface for example does not suffer from this limitation. By not considering ESP to be an IPv6 header we can allow sending those packets out to the host on all types of network interfaces. Fixes: 75020a702151 ("Common definitions for VMWARE devices") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/149 Buglink: https://bugs.launchpad.net/qemu/+bug/1758091 Signed-off-by: Thomas Jansen <mithi@mithi.net> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14hw/net: e1000e: Clear ICR on read when using non MSI-X interruptsNick Hudson2-0/+6
In section 7.4.3 of the 82574 datasheet it states that "In systems that do not support MSI-X, reading the ICR register clears it's bits..." Some OSes rely on this. Signed-off-by: Nick Hudson <skrll@netbsd.org> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14net/filter: Optimize filter_send to coroutineRao Lei1-13/+53
This patch is to improve the logic of QEMU main thread sleep code in qemu_chr_write_buffer() where it can be blocked and can't run other coroutines during COLO IO stress test. Our approach is to put filter_send() in a coroutine. In this way, filter_send() will call qemu_coroutine_yield() in qemu_co_sleep_ns(), so that it can be scheduled out and QEMU main thread has opportunity to run other tasks. Signed-off-by: Lei Rao <lei.rao@intel.com> Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14net/colo-compare.c: Update the default value commentsZhang Chen1-1/+1
Make the comments consistent with the REGULAR_PACKET_CHECK_MS. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14net/colo-compare.c: Optimize compare order for performanceZhang Chen1-13/+13
COLO-compare use the glib function g_queue_find_custom to dump another VM's networking packet to compare. But this function always start find from the queue->head(here is the newest packet), It will reduce the success rate of comparison. So this patch reversed the order of the queues for performance. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Reported-by: leirao <lei.rao@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14net: Fix uninitialized data usagePeter Foley1-0/+1
e.g. 1109 15:16:20.151506 Uninitialized bytes in ioctl_common_pre at offset 0 inside [0x7ffc516af9b8, 4) 1109 15:16:20.151659 ==588974==WARNING: MemorySanitizer: use-of-uninitialized-value 1109 15:16:20.312923 #0 0x5639b88acb21 in tap_probe_vnet_hdr_len third_party/qemu/net/tap-linux.c:183:9 1109 15:16:20.312952 #1 0x5639b88afd66 in net_tap_fd_init third_party/qemu/net/tap.c:409:9 1109 15:16:20.312954 #2 0x5639b88b2d1b in net_init_tap_one third_party/qemu/net/tap.c:681:19 1109 15:16:20.312956 #3 0x5639b88b16a8 in net_init_tap third_party/qemu/net/tap.c:912:13 1109 15:16:20.312957 #4 0x5639b8890175 in net_client_init1 third_party/qemu/net/net.c:1110:9 1109 15:16:20.312958 #5 0x5639b888f912 in net_client_init third_party/qemu/net/net.c:1208:15 1109 15:16:20.312960 #6 0x5639b8894aa5 in net_param_nic third_party/qemu/net/net.c:1588:11 1109 15:16:20.312961 #7 0x5639b900cd18 in qemu_opts_foreach third_party/qemu/util/qemu-option.c:1135:14 1109 15:16:20.312962 #8 0x5639b889393c in net_init_clients third_party/qemu/net/net.c:1612:9 1109 15:16:20.312964 #9 0x5639b717aaf3 in qemu_create_late_backends third_party/qemu/softmmu/vl.c:1962:5 1109 15:16:20.312965 #10 0x5639b717aaf3 in qemu_init third_party/qemu/softmmu/vl.c:3694:5 1109 15:16:20.312967 #11 0x5639b71083b8 in main third_party/qemu/softmmu/main.c:49:5 1109 15:16:20.312968 #12 0x7f464de1d8d2 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x628d2) 1109 15:16:20.312969 #13 0x5639b6bbd389 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 1109 15:16:20.312970 1109 15:16:20.312975 Uninitialized value was stored to memory at 1109 15:16:20.313393 #0 0x5639b88acbee in tap_probe_vnet_hdr_len third_party/qemu/net/tap-linux.c 1109 15:16:20.313396 #1 0x5639b88afd66 in net_tap_fd_init third_party/qemu/net/tap.c:409:9 1109 15:16:20.313398 #2 0x5639b88b2d1b in net_init_tap_one third_party/qemu/net/tap.c:681:19 1109 15:16:20.313399 #3 0x5639b88b16a8 in net_init_tap third_party/qemu/net/tap.c:912:13 1109 15:16:20.313400 #4 0x5639b8890175 in net_client_init1 third_party/qemu/net/net.c:1110:9 1109 15:16:20.313401 #5 0x5639b888f912 in net_client_init third_party/qemu/net/net.c:1208:15 1109 15:16:20.313403 #6 0x5639b8894aa5 in net_param_nic third_party/qemu/net/net.c:1588:11 1109 15:16:20.313404 #7 0x5639b900cd18 in qemu_opts_foreach third_party/qemu/util/qemu-option.c:1135:14 1109 15:16:20.313405 #8 0x5639b889393c in net_init_clients third_party/qemu/net/net.c:1612:9 1109 15:16:20.313407 #9 0x5639b717aaf3 in qemu_create_late_backends third_party/qemu/softmmu/vl.c:1962:5 1109 15:16:20.313408 #10 0x5639b717aaf3 in qemu_init third_party/qemu/softmmu/vl.c:3694:5 1109 15:16:20.313409 #11 0x5639b71083b8 in main third_party/qemu/softmmu/main.c:49:5 1109 15:16:20.313410 #12 0x7f464de1d8d2 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x628d2) 1109 15:16:20.313412 #13 0x5639b6bbd389 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 1109 15:16:20.313413 1109 15:16:20.313417 Uninitialized value was stored to memory at 1109 15:16:20.313791 #0 0x5639b88affbd in net_tap_fd_init third_party/qemu/net/tap.c:400:26 1109 15:16:20.313826 #1 0x5639b88b2d1b in net_init_tap_one third_party/qemu/net/tap.c:681:19 1109 15:16:20.313829 #2 0x5639b88b16a8 in net_init_tap third_party/qemu/net/tap.c:912:13 1109 15:16:20.313831 #3 0x5639b8890175 in net_client_init1 third_party/qemu/net/net.c:1110:9 1109 15:16:20.313836 #4 0x5639b888f912 in net_client_init third_party/qemu/net/net.c:1208:15 1109 15:16:20.313838 #5 0x5639b8894aa5 in net_param_nic third_party/qemu/net/net.c:1588:11 1109 15:16:20.313839 #6 0x5639b900cd18 in qemu_opts_foreach third_party/qemu/util/qemu-option.c:1135:14 1109 15:16:20.313841 #7 0x5639b889393c in net_init_clients third_party/qemu/net/net.c:1612:9 1109 15:16:20.313843 #8 0x5639b717aaf3 in qemu_create_late_backends third_party/qemu/softmmu/vl.c:1962:5 1109 15:16:20.313844 #9 0x5639b717aaf3 in qemu_init third_party/qemu/softmmu/vl.c:3694:5 1109 15:16:20.313845 #10 0x5639b71083b8 in main third_party/qemu/softmmu/main.c:49:5 1109 15:16:20.313846 #11 0x7f464de1d8d2 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x628d2) 1109 15:16:20.313847 #12 0x5639b6bbd389 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 1109 15:16:20.313849 1109 15:16:20.313851 Uninitialized value was created by an allocation of 'ifr' in the stack frame of function 'tap_probe_vnet_hdr' 1109 15:16:20.313855 #0 0x5639b88ac680 in tap_probe_vnet_hdr third_party/qemu/net/tap-linux.c:151 1109 15:16:20.313856 1109 15:16:20.313878 SUMMARY: MemorySanitizer: use-of-uninitialized-value third_party/qemu/net/tap-linux.c:183:9 in tap_probe_vnet_hdr_len Fixes: dc69004c7d8 ("net: move tap_probe_vnet_hdr() to tap-linux.c") Reviewed-by: Hao Wu <wuhaotsh@google.com> Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Foley <pefoley@google.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14net/tap: Set return code on failurePeter Foley1-0/+1
Match the other error handling in this function. Fixes: e7b347d0bf6 ("net: detect errors from probing vnet hdr flag for TAP devices") Reviewed-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Foley <pefoley@google.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-14hw/net/vmxnet3: Log guest-triggerable errors using LOG_GUEST_ERRORPhilippe Mathieu-Daudé1-1/+3
The "Interrupt Cause" register (VMXNET3_REG_ICR) is read-only. Write accesses are ignored. Log them with as LOG_GUEST_ERROR instead of aborting: [R +0.239743] writeq 0xe0002031 0x46291a5a55460800 ERROR:hw/net/vmxnet3.c:1819:vmxnet3_io_bar1_write: code should not be reached Thread 1 "qemu-system-i38" received signal SIGABRT, Aborted. (gdb) bt #3 0x74c397d3 in __GI_abort () at abort.c:79 #4 0x76d3cd4c in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, message=<optimized out>) at ../glib/gtestutils.c:3223 #5 0x76d9d45f in g_assertion_message_expr (domain=0x0, file=0x59fc2e53 "hw/net/vmxnet3.c", line=1819, func=0x59fc11e0 <__func__.vmxnet3_io_bar1_write> "vmxnet3_io_bar1_write", expr=<optimized out>) at ../glib/gtestutils.c:3249 #6 0x57e80a3a in vmxnet3_io_bar1_write (opaque=0x62814100, addr=56, val=70, size=4) at hw/net/vmxnet3.c:1819 #7 0x58c2d894 in memory_region_write_accessor (mr=0x62816b90, addr=56, value=0x7fff9450, size=4, shift=0, mask=4294967295, attrs=...) at softmmu/memory.c:492 #8 0x58c2d1d2 in access_with_adjusted_size (addr=56, value=0x7fff9450, size=1, access_size_min=4, access_size_max=4, access_fn= 0x58c2d290 <memory_region_write_accessor>, mr=0x62816b90, attrs=...) at softmmu/memory.c:554 #9 0x58c2bae7 in memory_region_dispatch_write (mr=0x62816b90, addr=56, data=70, op=MO_8, attrs=...) at softmmu/memory.c:1504 #10 0x58bfd034 in flatview_write_continue (fv=0x606000181700, addr=0xe0002038, attrs=..., ptr=0x7fffb9e0, len=1, addr1=56, l=1, mr=0x62816b90) at softmmu/physmem.c:2782 #11 0x58beba00 in flatview_write (fv=0x606000181700, addr=0xe0002031, attrs=..., buf=0x7fffb9e0, len=8) at softmmu/physmem.c:2822 #12 0x58beb589 in address_space_write (as=0x608000015f20, addr=0xe0002031, attrs=..., buf=0x7fffb9e0, len=8) at softmmu/physmem.c:2914 Reported-by: Dike <dike199774@qq.com> Reported-by: Duhao <504224090@qq.com> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2032932 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
2022-02-11hw/block/fdc-isa: Respect QOM properties when building AMLBernhard Beschow1-4/+7
Other ISA devices such as serial-isa use the properties in their build_aml functions. fdc-isa not using them is probably an oversight. Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20220209191558.30393-1-shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-02-11iotests/281: Let NBD connection yield in iothreadHanna Reitz2-5/+27
Put an NBD block device into an I/O thread, and then read data from it, hoping that the NBD connection will yield during that read. When it does, the coroutine must be reentered in the block device's I/O thread, which will only happen if the NBD block driver attaches the connection's QIOChannel to the new AioContext. It did not do that after 4ddb5d2fde ("block/nbd: drop connection_co") and prior to "block/nbd: Move s->ioc on AioContext change", which would cause an assertion failure. To improve our chances of yielding, the NBD server is throttled to reading 64 kB/s, and the NBD client reads 128 kB, so it should yield at some point. Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11block/nbd: Move s->ioc on AioContext changeHanna Reitz1-0/+45
s->ioc must always be attached to the NBD node's AioContext. If that context changes, s->ioc must be attached to the new context. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2033626 Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11iotests/281: Test lingering timersHanna Reitz2-4/+79
Prior to "block/nbd: Delete reconnect delay timer when done" and "block/nbd: Delete open timer when done", both of those timers would remain scheduled even after successfully (re-)connecting to the server, and they would not even be deleted when the BDS is deleted. This test constructs exactly this situation: (1) Configure an @open-timeout, so the open timer is armed, and (2) Configure a @reconnect-delay and trigger a reconnect situation (which succeeds immediately), so the reconnect delay timer is armed. Then we immediately delete the BDS, and sleep for longer than the @open-timeout and @reconnect-delay. Prior to said patches, this caused one (or both) of the timer CBs to access already-freed data. Accessing freed data may or may not crash, so this test can produce false successes, but I do not know how to show the problem in a better or more reliable way. If you run this test on "block/nbd: Assert there are no timers when closed" and without the fix patches mentioned above, you should reliably see an assertion failure. (But all other tests that use the reconnect delay timer (264 and 277) will fail in that configuration, too; as will nbd-reconnect-on-open, which uses the open timer.) Remove this test from the quick group because of the two second sleep this patch introduces. (I decided to put this test case into 281, because the main bug this series addresses is in the interaction of the NBD block driver and I/O threads, which is precisely the scope of 281. The test case for that other bug will also be put into the test class added here. Also, excuse the test class's name, I couldn't come up with anything better. The "yield" part will make sense two patches from now.) Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11iotests.py: Add QemuStorageDaemon classHanna Reitz1-0/+40
This is a rather simple class that allows creating a QSD instance running in the background and stopping it when no longer needed. The __del__ handler is a safety net for when something goes so wrong in a test that e.g. the tearDown() method is not called (e.g. setUp() launches the QSD, but then launching a VM fails). We do not want the QSD to continue running after the test has failed, so __del__() will take care to kill it. Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11block/nbd: Assert there are no timers when closedHanna Reitz1-0/+4
Our two timers must not remain armed beyond nbd_clear_bdrvstate(), or they will access freed data when they fire. This patch is separate from the patches that actually fix the issue (HEAD^^ and HEAD^) so that you can run the associated regression iotest (281) on a configuration that reproducibly exposes the bug. Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11block/nbd: Delete open timer when doneHanna Reitz1-0/+8
We start the open timer to cancel the connection attempt after a while. Once nbd_do_establish_connection() has returned, the attempt is over, and we no longer need the timer. Delete it before returning from nbd_open(), so that it does not persist for longer. It has no use after nbd_open(), and just like the reconnect delay timer, it might well be dangerous if it were to fire afterwards. Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11block/nbd: Delete reconnect delay timer when doneHanna Reitz1-0/+7
We start the reconnect delay timer to cancel the reconnection attempt after a while. Once nbd_co_do_establish_connection() has returned, this attempt is over, and we no longer need the timer. Delete it before returning from nbd_reconnect_attempt(), so that it does not persist beyond the I/O request that was paused for reconnecting; we do not want it to fire in a drained section, because all sort of things can happen in such a section (e.g. the AioContext might be changed, and we do not want the timer to fire in the wrong context; or the BDS might even be deleted, and so the timer CB would access already-freed data). Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2022-02-11iotests: Test blockdev-reopen with iothreads and throttlingKevin Wolf2-5/+35
The 'throttle' block driver implements .bdrv_co_drain_end, so blockdev-reopen will have to wait for it to complete in the polling loop at the end of qmp_blockdev_reopen(). This makes AIO_WAIT_WHILE() release the AioContext lock, which causes a crash if the lock hasn't correctly been taken. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220203140534.36522-3-kwolf@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-02-11block: Lock AioContext for drain_end in blockdev-reopenKevin Wolf1-1/+10
bdrv_subtree_drained_end() requires the caller to hold the AioContext lock for the drained node. Not doing this for nodes outside of the main AioContext leads to crashes when AIO_WAIT_WHILE() needs to wait and tries to temporarily release the lock. Fixes: 3908b7a8994fa5ef7a89aa58cd5a02fc58141592 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2046659 Reported-by: Qing Wang <qinwang@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20220203140534.36522-2-kwolf@redhat.com> Reviewed-by: Hanna Reitz <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-02-09include/exec: fix softmmu version of TARGET_ABI_FMT_lxAlex Bennée1-1/+1
TARGET_ABI_FMT_lx isn't available for softmmu which causes confusion when trying to print. As abi_ptr == target_ulong use its format string instead. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2022-02-09linux-user: Remove the deprecated ppc64abi32 targetThomas Huth12-88/+21
It's likely broken, and nobody cared for picking it up again during the deprecation phase, so let's remove this now. Since this is the last entry in deprecated_targets_list, remove the related code in the configure script, too. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Cédric Le Goater <clg@kaod.org> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20211215084958.185214-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220112112722.3641051-32-alex.bennee@linaro.org>
2022-02-09plugins: move reset of plugin data to tb_startAlex Bennée1-11/+20
We can't always guarantee we get to the end of a translator loop. Although this can happen for a variety of reasons it does happen more often on x86 system emulation when an instruction spans across to an un-faulted page. This caused confusion of the instruction tracking data resulting in apparent reverse execution (at least from the plugins point of view). Fix this by moving the reset code to plugin_gen_tb_start so we always start with a clean slate. We unconditionally reset tcg_ctx->plugin_insn as the plugin_insn_append code uses this as a proxy for knowing if plugins are enabled for the current instruction. Otherwise we can hit a race where a previously instrumented thread leaves a stale value after the main thread exits and disables instrumentation. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/824 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-27-alex.bennee@linaro.org>
2022-02-09target/i386: use CPU_LOG_INT for IRQ servicingAlex Bennée1-2/+2
I think these have been wrong since f193c7979c (do not depend on thunk.h - more log items). Fix them so as not to confuse other debugging. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220204204335.1689602-26-alex.bennee@linaro.org>
2022-02-09tests/plugins: add instruction matching to libinsn.soAlex Bennée1-1/+88
This adds simple instruction matching to the libinsn.so plugin which is useful for examining the execution distance between instructions. For example to track how often we flush in ARM due to TLB updates: -plugin ./tests/plugin/libinsn.so,match=tlbi which leads to output like this: 0xffffffc01019a918, 'tlbi vale1is, x1', 5702 hits, 31825 match hits, Δ+8112 since last match, 68859 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5703 hits, 56593 match hits, Δ+17712125 since last match, 33455 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5704 hits, 56594 match hits, Δ+12689 since last match, 33454 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5705 hits, 56595 match hits, Δ+12585 since last match, 33454 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5706 hits, 56596 match hits, Δ+10491 since last match, 33454 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5707 hits, 56597 match hits, Δ+4721 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5708 hits, 56598 match hits, Δ+10733 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5709 hits, 56599 match hits, Δ+61959 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5710 hits, 56600 match hits, Δ+55235 since last match, 33454 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5711 hits, 56601 match hits, Δ+54373 since last match, 33454 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5712 hits, 56602 match hits, Δ+2705 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5713 hits, 56603 match hits, Δ+17262 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5714 hits, 56604 match hits, Δ+17206 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5715 hits, 56605 match hits, Δ+28940 since last match, 33453 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5716 hits, 56606 match hits, Δ+7370 since last match, 33452 avg insns/match 0xffffffc01019a918, 'tlbi vale1is, x1', 5717 hits, 56607 match hits, Δ+7066 since last match, 33452 avg insns/match showing we do some sort of TLBI invalidation every 33 thousand instructions. Cc: Vasilev Oleg <vasilev.oleg@huawei.com> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Emilio Cota <cota@braap.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-25-alex.bennee@linaro.org>
2022-02-09tests/plugin: allow libinsn.so per-CPU countsAlex Bennée1-8/+31
We won't go fully flexible but for most system emulation 8 vCPUs resolution should be enough for anybody ;-) Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-24-alex.bennee@linaro.org>
2022-02-09contrib/plugins: add a drcov pluginIvanov Arkady2-0/+164
This patch adds the ability to generate files in drcov format. Primary goal this script is to have coverage logfiles thatwork in Lighthouse. Signed-off-by: Ivanov Arkady <arkadiy.ivanov@ispras.ru> Message-Id: <163491884553.304355.13246023070235438959.stgit@pc-System-Product-Name> [AJB: use g_ptr_array instead of slist] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-23-alex.bennee@linaro.org>
2022-02-09plugins: add helper functions for coverage pluginsIvanov Arkady3-0/+86
Which provide information about: - start_code. - end_code. - entry. - path to the executable binary. Signed-off-by: Ivanov Arkady <arkadiy.ivanov@ispras.ru> Message-Id: <163491883461.304355.8210754161847179432.stgit@pc-System-Product-Name> [AJB: reword title, better descriptions, defaults, rm export, fix include] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-22-alex.bennee@linaro.org>
2022-02-09tracing: excise the tcg related from tracetoolAlex Bennée9-350/+4
Now we have no TCG trace events and no longer handle them in the code we can remove the handling from the tracetool to generate them. vcpu tracing is still available although the existing syscall event is an exercise in redundancy (plugins and -strace can also get the information). Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-21-alex.bennee@linaro.org>
2022-02-09tracing: remove the trace-tcg includes from the buildAlex Bennée4-9/+0
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-20-alex.bennee@linaro.org>
2022-02-09tracing: remove TCG memory access tracingAlex Bennée6-67/+0
If you really want to trace all memory operations TCG plugins gives you a more flexible interface for doing so. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-19-alex.bennee@linaro.org>
2022-02-09docs: remove references to TCG tracingAlex Bennée2-85/+13
Users wanting this sort of functionality should turn to TCG plugins instead. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Cc: Luis Vilanova <vilanova@imperial.ac.uk> Cc: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20220204204335.1689602-18-alex.bennee@linaro.org>
2022-02-09tests/tcg/sh4: disable another unreliable testAlex Bennée1-0/+4
Given the other failures it looks like general thread handling on sh4 is sketchy. It fails more often on CI than on my developer machine though. See https://gitlab.com/qemu-project/qemu/-/issues/856 for more details. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Laurent Vivier <laurent@vivier.eu> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-17-alex.bennee@linaro.org>
2022-02-09tests: Update CentOS 8 container to CentOS Stream 8Thomas Huth2-3/+3
Support for CentOS 8 has stopped at the end of 2021, so let's switch to the Stream variant instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220201101911.97900-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-16-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Allow lcitool-refresh in out-of-tree builds, tooThomas Huth1-1/+1
When running "make lcitool-refresh" in an out-of-tree build, it currently fails with an error message from git like this: fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Fix it by changing to the source directory first before updating the submodule. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220201085554.85733-1-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-15-alex.bennee@linaro.org>
2022-02-09gitlab: fall back to commit hash in qemu-setup filenameStefan Hajnoczi1-1/+1
Personal repos may not have release tags (v6.0.0, v6.1.0, etc) and this causes cross_system_build_job to fail when pretty-printing a unique qemu-setup-*.exe name: version="$(git describe --match v[0-9]*)"; ^^^^^^^^^^ fails ^^^^^^^^^^^ mv -v qemu-setup*.exe qemu-setup-${version}.exe; Fall back to the short commit hash if necessary. This fixes CI failures that Greg Kurz and I experienced in our personal repos. Cc: Greg Kurz <groug@kaod.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220125173454.10381-1-stefanha@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220204204335.1689602-14-alex.bennee@linaro.org>
2022-02-09docs/devel: mention our .editorconfigAlex Bennée1-0/+4
Ideally we should keep all our automatic formatting gubins in here. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220204204335.1689602-13-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Install libibumad to cover RDMA on Debian based distrosPhilippe Mathieu-Daudé3-0/+3
On Debian we also need libibumad to enable RDMA: $ ../configure --enable-rdma ERROR: OpenFabrics librdmacm/libibverbs/libibumad not present. Your options: (1) Fast: Install infiniband packages (devel) from your distro. (2) Cleanest: Install libraries from www.openfabrics.org (3) Also: Install softiwarp if you don't have RDMA hardware Add the dependency to lcitool's qemu.yml (where librdmacm and libibverbs are already listed) and refresh the generated files by running: $ make lcitool-refresh Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-8-f4bug@amsat.org> Message-Id: <20220204204335.1689602-12-alex.bennee@linaro.org>
2022-02-09tests: Manually remove libxml2 on MSYS2 runnersPhilippe Mathieu-Daudé2-3/+0
lcitool doesn't support MSYS2 targets, so manually remove this now unnecessary library. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-7-f4bug@amsat.org> Message-Id: <20220204204335.1689602-11-alex.bennee@linaro.org>
2022-02-09tests/lcitool: Refresh submodule and remove libxml2Philippe Mathieu-Daudé11-18/+10
The previous commit removed all uses of libxml2. Refresh lcitool submodule, update qemu.yml and refresh the generated files by running: $ make lcitool-refresh Note: This refreshment also removes libudev dependency on Fedora and CentOS due to libvirt-ci commit 18bfaee ("mappings: Improve mapping for libudev"), since "The udev project has been absorbed by the systemd project", and lttng-ust on FreeBSD runners due to libvirt-ci commit 6dd9b6f ("guests: drop lttng-ust from FreeBSD platform"). Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20220121154134.315047-6-f4bug@amsat.org> Message-Id: <20220204204335.1689602-10-alex.bennee@linaro.org>