| 0041b5a | Yao Xingtao | 19 March 2024, 02:16:10 UTC | monitor/hmp-cmds-target: Append a space in error message in gpa2hva() In qemu monitor mode, when we use gpa2hva command to print the host virtual address corresponding to a guest physical address, if the gpa is not in RAM, the error message is below: (qemu) gpa2hva 0x750000000 Memory at address 0x750000000is not RAM A space is missed between '0x750000000' and 'is'. Signed-off-by: Yao Xingtao <yaoxt.fnst@fujitsu.com> Fixes: e9628441df ("hmp: gpa2hva and gpa2hpa hostaddr command") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org> Message-ID: <20240319021610.2423844-1-ruansy.fnst@fujitsu.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit a158c63b3ba120f1656e4dd815d186c623fb5ef6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:49:20 UTC |
| 783b2fc | Lorenz Brun | 15 March 2024, 14:58:31 UTC | hw/scsi/scsi-generic: Fix io_timeout property not applying The io_timeout property, introduced in c9b6609 (part of 6.0) is silently overwritten by the hardcoded default value of 30 seconds (DEFAULT_IO_TIMEOUT) in scsi_generic_realize because that function is being called after the properties have already been applied. The property definition already has a default value which is applied correctly when no value is explicitly set, so we can just remove the code which overrides the io_timeout completely. This has been tested by stracing SG_IO operations with the io_timeout property set and unset and now sets the timeout field in the ioctl request to the proper value. Fixes: c9b6609b69facad ("scsi: make io_timeout configurable") Signed-off-by: Lorenz Brun <lorenz@brun.one> Message-ID: <20240315145831.2531695-1-lorenz@brun.one> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 7c7a9f578e4fb1adff7ac8d9acaaaedb87474e76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:48:06 UTC |
| 78bebf8 | Gregory Price | 07 March 2024, 15:53:04 UTC | target/i386/tcg: Enable page walking from MMIO memory CXL emulation of interleave requires read and write hooks due to requirement for subpage granularity. The Linux kernel stack now enables using this memory as conventional memory in a separate NUMA node. If a process is deliberately forced to run from that node $ numactl --membind=1 ls the page table walk on i386 fails. Useful part of backtrace: (cpu=cpu@entry=0x555556fd9000, fmt=fmt@entry=0x555555fe3378 "cpu_io_recompile: could not find TB for pc=%p") at ../../cpu-target.c:359 (retaddr=0, addr=19595792376, attrs=..., xlat=<optimized out>, cpu=0x555556fd9000, out_offset=<synthetic pointer>) at ../../accel/tcg/cputlb.c:1339 (cpu=0x555556fd9000, full=0x7fffee0d96e0, ret_be=ret_be@entry=0, addr=19595792376, size=size@entry=8, mmu_idx=4, type=MMU_DATA_LOAD, ra=0) at ../../accel/tcg/cputlb.c:2030 (cpu=cpu@entry=0x555556fd9000, p=p@entry=0x7ffff56fddc0, mmu_idx=<optimized out>, type=type@entry=MMU_DATA_LOAD, memop=<optimized out>, ra=ra@entry=0) at ../../accel/tcg/cputlb.c:2356 (cpu=cpu@entry=0x555556fd9000, addr=addr@entry=19595792376, oi=oi@entry=52, ra=ra@entry=0, access_type=access_type@entry=MMU_DATA_LOAD) at ../../accel/tcg/cputlb.c:2439 at ../../accel/tcg/ldst_common.c.inc:301 at ../../target/i386/tcg/sysemu/excp_helper.c:173 (err=0x7ffff56fdf80, out=0x7ffff56fdf70, mmu_idx=0, access_type=MMU_INST_FETCH, addr=18446744072116178925, env=0x555556fdb7c0) at ../../target/i386/tcg/sysemu/excp_helper.c:578 (cs=0x555556fd9000, addr=18446744072116178925, size=<optimized out>, access_type=MMU_INST_FETCH, mmu_idx=0, probe=<optimized out>, retaddr=0) at ../../target/i386/tcg/sysemu/excp_helper.c:604 Avoid this by plumbing the address all the way down from x86_cpu_tlb_fill() where is available as retaddr to the actual accessors which provide it to probe_access_full() which already handles MMIO accesses. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2180 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2220 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Gregory Price <gregory.price@memverge.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-ID: <20240307155304.31241-2-Jonathan.Cameron@huawei.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 9dab7bbb017d11b64c52239fa4e2f910a6a004f2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:47:02 UTC |
| eaa2089 | Fiona Ebner | 22 March 2024, 09:50:09 UTC | iotests: add test for stream job with an unaligned prefetch read Previously, bdrv_pad_request() could not deal with a NULL qiov when a read needed to be aligned. During prefetch, a stream job will pass a NULL qiov. Add a test case to cover this scenario. By accident, also covers a previous race during shutdown, where block graph changes during iteration in bdrv_flush_all() could lead to unreferencing the wrong block driver state and an assertion failure later. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-5-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 12d7b3bbd3333cededd3b695501d8d247239d769) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:43:09 UTC |
| edba203 | Fiona Ebner | 22 March 2024, 09:50:08 UTC | block-backend: fix edge case in bdrv_next_cleanup() where BDS associated to BB changes Same rationale as for commit "block-backend: fix edge case in bdrv_next() where BDS associated to BB changes". The block graph might change between the bdrv_next() call and the bdrv_next_cleanup() call, so it could be that the associated BDS is not the same that was referenced previously anymore. Instead, rely on bdrv_next() to set it->bs to the BDS it referenced and unreference that one in any case. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-4-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit bac09b093ebbb79e6a7444c7b979c32ca5540132) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:42:57 UTC |
| 1652e5b | Fiona Ebner | 22 March 2024, 09:50:07 UTC | block-backend: fix edge case in bdrv_next() where BDS associated to BB changes The old_bs variable in bdrv_next() is currently determined by looking at the old block backend. However, if the block graph changes before the next bdrv_next() call, it might be that the associated BDS is not the same that was referenced previously. In that case, the wrong BDS is unreferenced, leading to an assertion failure later: > bdrv_unref: Assertion `bs->refcnt > 0' failed. In particular, this can happen in the context of bdrv_flush_all(), when polling for bdrv_co_flush() in the generated co-wrapper leads to a graph change (for example with a stream block job [0]). A racy reproducer: > #!/bin/bash > rm -f /tmp/backing.qcow2 > rm -f /tmp/top.qcow2 > ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M > ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2 > ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2 > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": "node0" } } > {"execute": "quit"} > EOF [0]: > #0 bdrv_replace_child_tran (child=..., new_bs=..., tran=...) > #1 bdrv_replace_node_noperm (from=..., to=..., auto_skip=..., tran=..., errp=...) > #2 bdrv_replace_node_common (from=..., to=..., auto_skip=..., detach_subchain=..., errp=...) > #3 bdrv_drop_filter (bs=..., errp=...) > #4 bdrv_cor_filter_drop (cor_filter_bs=...) > #5 stream_prepare (job=...) > #6 job_prepare_locked (job=...) > #7 job_txn_apply_locked (fn=..., job=...) > #8 job_do_finalize_locked (job=...) > #9 job_exit (opaque=...) > #10 aio_bh_poll (ctx=...) > #11 aio_poll (ctx=..., blocking=...) > #12 bdrv_poll_co (s=...) > #13 bdrv_flush (bs=...) > #14 bdrv_flush_all () > #15 do_vm_stop (state=..., send_stop=...) > #16 vm_shutdown () Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-3-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit f6d38c9f6dae6fce99dcaf6ca16a1fe5b5e19c4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:41:46 UTC |
| 80ccf1e | Stefan Reiter | 22 March 2024, 09:50:06 UTC | block/io: accept NULL qiov in bdrv_pad_request Some operations, e.g. block-stream, perform reads while discarding the results (only copy-on-read matters). In this case, they will pass NULL as the target QEMUIOVector, which will however trip bdrv_pad_request, since it wants to extend its passed vector. In particular, this is the case for the blk_co_preadv() call in stream_populate(). If there is no qiov, no operation can be done with it, but the bytes and offset still need to be updated, so the subsequent aligned read will actually be aligned and not run into an assertion failure. In particular, this can happen when the request alignment of the top node is larger than the allocated part of the bottom node, in which case padding becomes necessary. For example: > ./qemu-img create /tmp/backing.qcow2 -f qcow2 64M -o cluster_size=32768 > ./qemu-io -c "write -P42 0x0 0x1" /tmp/backing.qcow2 > ./qemu-img create /tmp/top.qcow2 -f qcow2 64M -b /tmp/backing.qcow2 -F qcow2 > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/top.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "blockdev-add", "arguments": { "driver": "compress", "file": "node0", "node-name": "node1" } } > {"execute": "block-stream", "arguments": { "job-id": "stream0", "device": "node1" } } > EOF Originally-by: Stefan Reiter <s.reiter@proxmox.com> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> [FE: do update bytes and offset in any case add reproducer to commit message] Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20240322095009.346989-2-f.ebner@proxmox.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 3f934817c82c2f1bf1c238f8d1065a3be10a3c9e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:41:46 UTC |
| 73d604a | Kevin Wolf | 15 March 2024, 15:59:49 UTC | vdpa-dev: Fix initialisation order to restore VDUSE compatibility VDUSE requires that virtqueues are first enabled before the DRIVER_OK status flag is set; with the current API of the kernel module, it is impossible to enable the opposite order in our block export code because userspace is not notified when a virtqueue is enabled. This requirement also mathces the normal initialisation order as done by the generic vhost code in QEMU. However, commit 6c482547 accidentally changed the order for vdpa-dev and broke access to VDUSE devices with this. This changes vdpa-dev to use the normal order again and use the standard vhost callback .vhost_set_vring_enable for this. VDUSE devices can be used with vdpa-dev again after this fix. vhost_net intentionally avoided enabling the vrings for vdpa and does this manually later while it does enable them for other vhost backends. Reflect this in the vhost_net code and return early for vdpa, so that the behaviour doesn't change for this device. Cc: qemu-stable@nongnu.org Fixes: 6c4825476a43 ('vdpa: move vhost_vdpa_set_vring_ready to the caller') Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240315155949.86066-1-kwolf@redhat.com> Reviewed-by: Eugenio Pérez <eperezma@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 2c66de61f88dc9620a32239f7dd61524a57f66b0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 March 2024, 06:39:28 UTC |
| 784ebe5 | Ido Plat | 18 March 2024, 20:27:10 UTC | target/s390x: Use mutable temporary value for op_ts Otherwise TCG would assume the register that holds t1 would be constant and reuse whenever it needs the value within it. Cc: qemu-stable@nongnu.org Fixes: f1ea739bd598 ("target/s390x: Use tcg_constant_* in local contexts") Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [iii: Adjust a newline and capitalization, add tags] Signed-off-by: Ido Plat <ido.plat@ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20240318202722.20675-1-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 272fba9779af0bb1c29cd30302fc1e31c59274d0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 25 March 2024, 19:13:29 UTC |
| ef9b43b | Song Gao | 21 March 2024, 12:36:06 UTC | target/loongarch: Fix qemu-system-loongarch64 assert failed with the option '-d int' qemu-system-loongarch64 assert failed with the option '-d int', the helper_idle() raise an exception EXCP_HLT, but the exception name is undefined. Signed-off-by: Song Gao <gaosong@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240321123606.1704900-1-gaosong@loongson.cn> (cherry picked from commit 1590154ee4376819a8c6ee61e849ebf4a4e7cd02) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 25 March 2024, 12:16:41 UTC |
| 358dd25 | Thomas Huth | 04 March 2024, 13:04:03 UTC | docs/conf.py: Remove usage of distutils The macOS jobs in our CI recently started failing, complaining that the distutils module is not available anymore. And indeed, according to https://peps.python.org/pep-0632/ it's been deprecated since a while and now likely got removed in recent Python versions. Fortunately, we only use it for a version check via LooseVersion here which we don't really need anymore - according to Repology.org, these are the versions of sphinx-rtd-theme that are currently used by the various distros: centos_stream_8: 0.3.1 centos_stream_9: 0.5.1 fedora_38: 1.1.1 fedora_39: 1.2.2 freebsd: 1.0.0 haikuports_master: 1.2.1 openbsd: 1.2.2 opensuse_leap_15_5: 0.5.1 pkgsrc_current: 2.0.0 debian_11: 0.5.1 debian_12: 1.2.0 ubuntu_20_04: 0.4.3 ubuntu_22_04: 1.0.0 ubuntu_24_04: 2.0.0 So except for CentOS 8, all distros are using a newer version of sphinx-rtd-theme, and for CentOS 8 we don't support compiling with the Sphinx of the distro anymore anyway, since it's based on the Python 3.6 interpreter there. For compiling on CentOS 8, you have to use the alternative Python 3.8 interpreter which comes without Sphinx, so that needs the Sphinx installed via pip in the venv instead, and that is using a newer version, too, according to our pythondeps.toml file. Thus we can simply drop the version check now to get rid of the distutils dependency here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-id: 20240304130403.129543-1-thuth@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit eb844330bd36ebdd4959053da08069d1e5d49119) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 March 2024, 14:37:35 UTC |
| 5b51920 | Song Gao | 20 March 2024, 01:39:55 UTC | target/loongarch: Fix qemu-loongarch64 hang when executing 'll.d $t0, $t0, 0' On gen_ll, if a->imm is zero, make_address_x return src1, but the load to destination may clobber src1. We use a new destination to fix this problem. Fixes: c5af6628f4be (target/loongarch: Extract make_address_i() helper) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Song Gao <gaosong@loongson.cn> Message-Id: <20240320013955.1561311-1-gaosong@loongson.cn> (cherry picked from commit 77642f92c0b71a105aba2a4d03bc62328eae703b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 March 2024, 04:49:24 UTC |
| 242370f | Sven Schnelle | 19 March 2024, 16:19:21 UTC | target/hppa: fix do_stdby_e() stdby,e,m was writing data from the wrong half of the register into memory for cases 0-3. Fixes: 25460fc5a71 ("target/hppa: Implement STDBY") Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240319161921.487080-7-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 518d2f4300e5c50a3e6416fd46e58373781a5267) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:56 UTC |
| b0a0ec4 | Sven Schnelle | 19 March 2024, 16:19:20 UTC | target/hppa: mask privilege bits in mfia mfia should return only the iaoq bits without privilege bits. Fixes: 98a9cb792c8 ("target-hppa: Implement system and memory-management insns") Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Helge Deller <deller@gmx.de> Message-Id: <20240319161921.487080-6-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit b5e0b3a53c983c4a9620a44a6a557b389e589218) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:51 UTC |
| e3b3cff | Sven Schnelle | 19 March 2024, 16:19:19 UTC | target/hppa: exit tb on flush cache instructions When the guest modifies the tb it is currently executing from, it executes a fic instruction. Exit the tb on such instruction, otherwise we might execute stale code. Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-Id: <20240319161921.487080-5-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ad1fdacd1b936557514dd72c2079a80be0c2dfb4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:47 UTC |
| 4dbeff3 | Sven Schnelle | 19 March 2024, 16:19:18 UTC | target/hppa: fix access_id check PA2.0 provides 8 instead of 4 PID registers. Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240319161921.487080-4-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit ae157fc25053917830c3b581bc282f906e6d95d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:41 UTC |
| ca52ee4 | Sven Schnelle | 19 March 2024, 16:19:17 UTC | target/hppa: fix shrp for wide mode Fixes: f7b775a9c075 ("target/hppa: Implement SHRPD") Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Helge Deller <deller@gmx.de> Message-Id: <20240319161921.487080-3-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit d37fad0ae5bd2c544fdb0f2eff6acdb28a155be0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:38 UTC |
| 4a76c56 | Sven Schnelle | 19 March 2024, 16:19:16 UTC | target/hppa: ldcw,s uses static shift of 3 Fixes: 96d6407f363 ("target-hppa: Implement loads and stores") Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240319161921.487080-2-svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit c3ea1996a14d5dbbedb3f9036f7ebec4395dc889) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:29 UTC |
| de74e73 | Richard Henderson | 03 March 2024, 01:48:48 UTC | target/hppa: Fix assemble_12a insns for wide mode Tested-by: Helge Deller <deller@gmx.de> Reported-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 46174e140d274385b1255bc7f16a5a711853053f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:12 UTC |
| efbcf7c | Richard Henderson | 03 March 2024, 01:38:17 UTC | target/hppa: Fix assemble_11a insns for wide mode Tested-by: Helge Deller <deller@gmx.de> Reviewed-by: Helge Deller <deller@gmx.de> Reported-by: Sven Schnelle <svens@stackframe.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4768c28edd4097ebef42822e15b4a43026b15376) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:32:00 UTC |
| f6f4703 | Richard Henderson | 03 March 2024, 01:10:00 UTC | target/hppa: Fix assemble_16 insns for wide mode Reported-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Helge Deller <deller@gmx.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 72bace2d13cb427fde3bb50ae1a71a2abe9acc0f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 21:31:32 UTC |
| cf794e4 | Tao Su | 20 March 2024, 08:36:40 UTC | target/i386: Revert monitor_puts() in do_inject_x86_mce() monitor_puts() doesn't check the monitor pointer, but do_inject_x86_mce() may have a parameter with NULL monitor pointer. Revert monitor_puts() in do_inject_x86_mce() to fix, then the fact that we send the same message to monitor and log is again more obvious. Fixes: bf0c50d4aa85 (monitor: expose monitor_puts to rest of code) Reviwed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Tao Su <tao1.su@linux.intel.com> Message-ID: <20240320083640.523287-1-tao1.su@linux.intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 7fd226b04746f0be0b636de5097f1b42338951a0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 17:16:22 UTC |
| f8fb592 | Marc-André Lureau | 19 March 2024, 09:25:02 UTC | ui: compile dbus-display1.c with -fPIC as necessary Building dbus-display1.c explicitly as a static library drops -fPIC by default, which may not be correct if it ends up linked to a shared library. Let the target decide how to build the unit, with or without -fPIC. This makes commit 186acfbaf7 ("tests/qtest: Depend on dbus_display1_dep") no longer relevant, as dbus-display1.c will be recompiled. Fixes: c172136ea33 ("meson: ensure dbus-display generated code is built before other units") Reported-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> (cherry picked from commit d4069a84a3380247c1b524096c6a807743bf687a) | 21 March 2024, 17:13:44 UTC |
| de742b1 | Daniel P. Berrangé | 18 March 2024, 13:03:19 UTC | Revert "chardev/char-socket: Fix TLS io channels sending too much data to the backend" This commit results in unexpected termination of the TLS connection. When 'fd_can_read' returns 0, the code goes on to pass a zero length buffer to qio_channel_read. The TLS impl calls into gnutls_recv() with this zero length buffer, at which point GNUTLS returns an error GNUTLS_E_INVALID_REQUEST. This is treated as fatal by QEMU's TLS code resulting in the connection being torn down by the chardev. Simply skipping the qio_channel_read when the buffer length is zero is also not satisfactory, as it results in a high CPU burn busy loop massively slowing QEMU's functionality. The proper solution is to avoid tcp_chr_read being called at all unless the frontend is able to accept more data. This will be done in a followup commit. This reverts commit 462945cd22d2bcd233401ed3aa167d83a8e35b05 Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit e8ee827ffdb86ebbd5f5213a1f78123c25a90864) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 21 March 2024, 17:00:22 UTC |
| 509525d | Paolo Bonzini | 11 March 2024, 07:56:44 UTC | target/i386: fix direction of "32-bit MMU" test The low bit of MMU indices for x86 TCG indicates whether the processor is in 32-bit mode and therefore linear addresses have to be masked to 32 bits. However, the index was computed incorrectly, leading to possible conflicts in the TLB for any address above 4G. Analyzed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: b1661801c18 ("target/i386: Fix physical address truncation", 2024-02-28) Fixes: a28b6b4e743 ("target/i386: Fix physical address truncation" in stable-8.2) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2206 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2cc68629a6fc198f4a972698bdd6477f883aedfb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: move changes for x86_cpu_mmu_index() to cpu_mmu_index() due to missing v8.2.0-1030-gace0c5fe59 "target/i386: Populate CPUClass.mmu_index") | 21 March 2024, 16:57:05 UTC |
| 1ced8cd | Paolo Bonzini | 02 January 2024, 14:40:18 UTC | target/i386: use separate MMU indexes for 32-bit accesses Accesses from a 32-bit environment (32-bit code segment for instruction accesses, EFER.LMA==0 for processor accesses) have to mask away the upper 32 bits of the address. While a bit wasteful, the easiest way to do so is to use separate MMU indexes. These days, QEMU anyway is compiled with a fixed value for NB_MMU_MODES. Split MMU_USER_IDX, MMU_KSMAP_IDX and MMU_KNOSMAP_IDX in two. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 90f641531c782c873a05895f411c05fbbbef3c49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: move changes for x86_cpu_mmu_index() to cpu_mmu_index() due to missing v8.2.0-1030-gace0c5fe59 "target/i386: Populate CPUClass.mmu_index") | 21 March 2024, 16:50:47 UTC |
| a85b8ec | Paolo Bonzini | 02 January 2024, 14:36:51 UTC | target/i386: introduce function to query MMU indices Remove knowledge of specific MMU indexes (other than MMU_NESTED_IDX and MMU_PHYS_IDX) from mmu_translate(). This will make it possible to split 32-bit and 64-bit MMU indexes. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 5f97afe2543f09160a8d123ab6e2e8c6d98fa9ce) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in target/i386/cpu.h due to other changes in that area) | 21 March 2024, 16:43:42 UTC |
| 25bdc64 | Kevin Wolf | 25 January 2024, 16:58:03 UTC | tests/unit: Bump test-replication timeout to 60 seconds We're seeing timeouts for this test on CI runs (specifically for ubuntu-20.04-s390x-all). It doesn't fail consistently, but even the successful runs take about 27 or 28 seconds, which is not very far from the 30 seconds timeout. Bump the timeout a bit to make failure less likely even on this CI host. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240125165803.48373-1-kwolf@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 63b18312d14ac984acaf13c7c55d9baa2d61496e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 March 2024, 14:33:40 UTC |
| 96ff214 | Thomas Huth | 15 December 2023, 07:03:55 UTC | tests/unit: Bump test-crypto-block test timeout to 5 minutes When running the tests in slow mode on a very loaded system and with --enable-debug, the test-crypto-block can take longer than 4 minutes. Bump the timeout to 5 minutes to make sure that it also passes in such situations. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-15-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit e1b363e328d559cd5f86d3d1d7b84d0154e153d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 March 2024, 14:33:21 UTC |
| 2a1ce7c | Thomas Huth | 15 December 2023, 07:03:54 UTC | tests/unit: Bump test-aio-multithread test timeout to 2 minutes When running the tests in slow mode on a very loaded system and with --enable-debug, the test-aio-multithread can take longer than 1 minute. Bump the timeout to two minutes to make sure that it also passes in such situations. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-14-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit c45f8f1aef35730a2dcf3cabe296ac12965db43d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 March 2024, 14:31:48 UTC |
| ddf4412 | Kevin Wolf | 14 March 2024, 16:58:25 UTC | iotests: Add test for reset/AioContext switches with NBD exports This replicates the scenario in which the bug was reported. Unfortunately this relies on actually executing a guest (so that the firmware initialises the virtio-blk device and moves it to its configured iothread), so this can't make use of the qtest accelerator like most other test cases. I tried to find a different easy way to trigger the bug, but couldn't find one. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240314165825.40261-3-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit e8fce34eccf68a32f4ecf2c6f121ff2ac383d6bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:50:08 UTC |
| a69a002 | Kevin Wolf | 14 March 2024, 16:58:24 UTC | nbd/server: Fix race in draining the export When draining an NBD export, nbd_drained_begin() first sets client->quiescing so that nbd_client_receive_next_request() won't start any new request coroutines. Then nbd_drained_poll() tries to makes sure that we wait for any existing request coroutines by checking that client->nb_requests has become 0. However, there is a small window between creating a new request coroutine and increasing client->nb_requests. If a coroutine is in this state, it won't be waited for and drain returns too early. In the context of switching to a different AioContext, this means that blk_aio_attached() will see client->recv_coroutine != NULL and fail its assertion. Fix this by increasing client->nb_requests immediately when starting the coroutine. Doing this after the checks if we should create a new coroutine is okay because client->lock is held. Cc: qemu-stable@nongnu.org Fixes: fd6afc501a01 ("nbd/server: Use drained block ops to quiesce the server") Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240314165825.40261-2-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 9c707525cbb1dd1e56876e45c70c0c08f2876d41) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:45:55 UTC |
| 13fc21a | Stefan Hajnoczi | 21 December 2023, 19:24:52 UTC | nbd/server: introduce NBDClient->lock to protect fields NBDClient has a number of fields that are accessed by both the export AioContext and the main loop thread. When the AioContext lock is removed these fields will need another form of protection. Add NBDClient->lock and protect fields that are accessed by both threads. Also add assertions where possible and otherwise add doc comments stating assumptions about which thread and lock holding. Note this patch moves the client->recv_coroutine assertion from nbd_co_receive_request() to nbd_trip() where client->lock is held. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231221192452.1785567-7-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 7075d235114b40b30524cf1c5b61906c0bbf5f4d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:45:50 UTC |
| aee1039 | Stefan Hajnoczi | 21 December 2023, 19:24:51 UTC | nbd/server: only traverse NBDExport->clients from main loop thread The NBD clients list is currently accessed from both the export AioContext and the main loop thread. When the AioContext lock is removed there will be nothing protecting the clients list. Adding a lock around the clients list is tricky because NBDClient structs are refcounted and may be freed from the export AioContext or the main loop thread. nbd_export_request_shutdown() -> client_close() -> nbd_client_put() is also tricky because the list lock would be held while indirectly dropping references to NDBClients. A simpler approach is to only allow nbd_client_put() and client_close() calls from the main loop thread. Then the NBD clients list is only accessed from the main loop thread and no fancy locking is needed. nbd_trip() just needs to reschedule itself in the main loop AioContext before calling nbd_client_put() and client_close(). This costs more CPU cycles per NBD request so add nbd_client_put_nonzero() to optimize the common case where more references to NBDClient remain. Note that nbd_client_get() can still be called from either thread, so make NBDClient->refcount atomic. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231221192452.1785567-6-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit f816310d0c32c8482e56807ea0f9faa8d1b5f696) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:41:38 UTC |
| 0d83579 | Kevin Wolf | 13 March 2024, 15:30:00 UTC | mirror: Don't call job_pause_point() under graph lock Calling job_pause_point() while holding the graph reader lock potentially results in a deadlock: bdrv_graph_wrlock() first drains everything, including the mirror job, which pauses it. The job is only unpaused at the end of the drain section, which is when the graph writer lock has been successfully taken. However, if the job happens to be paused at a pause point where it still holds the reader lock, the writer lock can't be taken as long as the job is still paused. Mark job_pause_point() as GRAPH_UNLOCKED and fix mirror accordingly. Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-28125 Fixes: 004915a96a7a ("block: Protect bs->backing with graph_lock") Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20240313153000.33121-1-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit ae5a40e8581185654a667fbbf7e4adbc2a2a3e45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:24:17 UTC |
| 8996768 | Cédric Le Goater | 12 March 2024, 12:04:31 UTC | migration: Skip only empty block devices The block .save_setup() handler calls a helper routine init_blk_migration() which builds a list of block devices to take into account for migration. When one device is found to be empty (sectors == 0), the loop exits and all the remaining devices are ignored. This is a regression introduced when bdrv_iterate() was removed. Change that by skipping only empty devices. Cc: Markus Armbruster <armbru@redhat.com> Cc: qemu-stable <qemu-stable@nongnu.org> Suggested-by: Kevin Wolf <kwolf@redhat.com> Fixes: fea68bb6e9fa ("block: Eliminate bdrv_iterate(), use bdrv_next()") Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Link: https://lore.kernel.org/r/20240312120431.550054-1-clg@redhat.com [peterx: fix "Suggested-by:"] Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 2e128776dc56f502c2ee41750afe83938f389528) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 19 March 2024, 16:22:46 UTC |
| 7820b9b | Volker Rümelin | 18 February 2024, 08:33:41 UTC | hw/audio/virtio-sound: return correct command response size The payload size returned by command VIRTIO_SND_R_PCM_INFO is wrong. The code in process_cmd() assumes that all commands return only a virtio_snd_hdr payload, but some commands like VIRTIO_SND_R_PCM_INFO may return an additional payload. Add a zero initialized payload_size variable to struct virtio_snd_ctrl_command to allow for additional payloads. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20240218083351.8524-1-vr_qemu@t-online.de> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 633487df8d303b37a88584d5a57a39dbcd91c7bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 18:52:34 UTC |
| b5c6660 | Jonathan Cameron | 07 March 2024, 16:03:26 UTC | hmat acpi: Fix out of bounds access due to missing use of indirection With a numa set up such as -numa nodeid=0,cpus=0 \ -numa nodeid=1,memdev=mem \ -numa nodeid=2,cpus=1 and appropriate hmat_lb entries the initiator list is correctly computed and writen to HMAT as 0,2 but then the LB data is accessed using the node id (here 2), landing outside the entry_list array. Stash the reverse lookup when writing the initiator list and use it to get the correct array index index. Fixes: 4586a2cb83 ("hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)") Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20240307160326.31570-3-Jonathan.Cameron@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 74e2845c5f95b0c139c79233ddb65bb17f2dd679) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 18:52:34 UTC |
| 313e746 | Akihiko Odaki | 28 February 2024, 11:33:13 UTC | pcie_sriov: Validate NumVFs The guest may write NumVFs greater than TotalVFs and that can lead to buffer overflow in VF implementations. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26327 Fixes: 7c0fa8dff811 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-2-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com> (cherry picked from commit 6081b4243cd64dff1b2cf5b0c215c71e9d7e753b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 18:52:34 UTC |
| 98f3488 | Akihiko Odaki | 28 February 2024, 11:33:12 UTC | hw/nvme: Use pcie_sriov_num_vfs() nvme_sriov_pre_write_ctrl() used to directly inspect SR-IOV configurations to know the number of VFs being disabled due to SR-IOV configuration writes, but the logic was flawed and resulted in out-of-bound memory access. It assumed PCI_SRIOV_NUM_VF always has the number of currently enabled VFs, but it actually doesn't in the following cases: - PCI_SRIOV_NUM_VF has been set but PCI_SRIOV_CTRL_VFE has never been. - PCI_SRIOV_NUM_VF was written after PCI_SRIOV_CTRL_VFE was set. - VFs were only partially enabled because of realization failure. It is a responsibility of pcie_sriov to interpret SR-IOV configurations and pcie_sriov does it correctly, so use pcie_sriov_num_vfs(), which it provides, to get the number of enabled VFs before and after SR-IOV configuration writes. Cc: qemu-stable@nongnu.org Fixes: CVE-2024-26328 Fixes: 11871f53ef8e ("hw/nvme: Add support for the Virtualization Management command") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20240228-reuse-v8-1-282660281e60@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 91bb64a8d2014fda33a81fcf0fce37340f0d3b0c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 18:52:34 UTC |
| 3097bcb | Klaus Jensen | 10 March 2024, 10:43:55 UTC | hw/nvme: add machine compatibility parameter to enable msix exclusive bar Commit 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") moved the MSI-X table and PBA to BAR 0 to make room for enabling CMR and PMR at the same time. As reported by Julien Grall in #2184, this breaks migration through system hibernation. Add a machine compatibility parameter and set it on machines pre 6.0 to enable the old behavior automatically, restoring the hibernation migration support. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2184 Fixes: 1901b4967c3f ("hw/block/nvme: move msix table and pba to BAR 0") Reported-by: Julien Grall julien@xen.org Tested-by: Julien Grall julien@xen.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit fa905f65c5549703279f68c253914799b10ada47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 17:36:57 UTC |
| 273111c | Klaus Jensen | 10 March 2024, 10:39:25 UTC | hw/nvme: generalize the mbar size helper Generalize the mbar size helper such that it can handle cases where the MSI-X table and PBA are expected to be in an exclusive bar. Cc: qemu-stable@nongnu.org Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit ee7bda4d38cda3eaf114c850a723dd12e23d3abc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 17:36:57 UTC |
| 389f665 | Klaus Jensen | 08 February 2024, 12:22:48 UTC | hw/nvme: fix invalid check on mcl The number of logical blocks within a source range is converted into a 1s based number at the time of parsing. However, when verifying the copy length we add one again, causing the check against MCL to fail in error. Cc: qemu-stable@nongnu.org Fixes: 381ab99d8587 ("hw/nvme: check maximum copy length (MCL) for COPY") Reviewed-by: Minwoo Im <minwoo.im@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 8c78015a55d84c016da6d5e41b6b5f618ecb25ab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 17:35:36 UTC |
| 2d281e0 | Minwoo Im | 09 January 2024, 02:29:53 UTC | hw/nvme: separate 'serial' property for VFs Currently, when a VF is created, it uses the 'params' object of the PF as it is. In other words, the 'params.serial' string memory area is also shared. In this situation, if the VF is removed from the system, the PF's 'params.serial' object is released with object_finalize() followed by object_property_del_all() which release the memory for 'serial' property. If that happens, the next VF created will inherit a serial from a corrupted memory area. If this happens, an error will occur when comparing subsys->serial and n->params.serial in the nvme_subsys_register_ctrl() function. Cc: qemu-stable@nongnu.org Fixes: 44c2c09488db ("hw/nvme: Add support for SR-IOV") Signed-off-by: Minwoo Im <minwoo.im@samsung.com> Reviewed-by: Klaus Jensen <k.jensen@samsung.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 4f0a4a3d5854824e5c5eccf353d4a1f4f749a29d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 17:34:30 UTC |
| 35ca0f7 | Peng Fan | 24 January 2024, 02:14:50 UTC | xen: Drop out of coroutine context xen_invalidate_map_cache_entry xen_invalidate_map_cache_entry is not expected to run in a coroutine. Without this, there is crash: signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 threadid=<optimized out>) at pthread_kill.c:78 at /usr/src/debug/glibc/2.38+git-r0/sysdeps/posix/raise.c:26 fmt=0xffff9e1ca8a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xaaaae0d25740 "!qemu_in_coroutine()", file=file@entry=0xaaaae0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xaaaae0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:92 assertion=assertion@entry=0xaaaae0d25740 "!qemu_in_coroutine()", file=file@entry=0xaaaae0d301a8 "../qemu-xen-dir-remote/block/graph-lock.c", line=line@entry=260, function=function@entry=0xaaaae0e522c0 <__PRETTY_FUNCTION__.3> "bdrv_graph_rdlock_main_loop") at assert.c:101 at ../qemu-xen-dir-remote/block/graph-lock.c:260 at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/block/graph-lock.h:259 host=host@entry=0xffff742c8000, size=size@entry=2097152) at ../qemu-xen-dir-remote/block/io.c:3362 host=0xffff742c8000, size=2097152) at ../qemu-xen-dir-remote/block/block-backend.c:2859 host=<optimized out>, size=<optimized out>, max_size=<optimized out>) at ../qemu-xen-dir-remote/block/block-ram-registrar.c:33 size=2097152, max_size=2097152) at ../qemu-xen-dir-remote/hw/core/numa.c:883 buffer=buffer@entry=0xffff743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:475 buffer=buffer@entry=0xffff743c5000 "") at ../qemu-xen-dir-remote/hw/xen/xen-mapcache.c:487 as=as@entry=0xaaaae1ca3ae8 <address_space_memory>, buffer=0xffff743c5000, len=<optimized out>, is_write=is_write@entry=true, access_len=access_len@entry=32768) at ../qemu-xen-dir-remote/system/physmem.c:3199 dir=DMA_DIRECTION_FROM_DEVICE, len=<optimized out>, buffer=<optimized out>, as=0xaaaae1ca3ae8 <address_space_memory>) at /home/Freenix/work/sw-stash/xen/upstream/tools/qemu-xen-dir-remote/include/sysemu/dma.h:236 elem=elem@entry=0xaaaaf620aa30, len=len@entry=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:758 elem=elem@entry=0xaaaaf620aa30, len=len@entry=32769, idx=idx@entry=0) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:919 elem=elem@entry=0xaaaaf620aa30, len=32769) at ../qemu-xen-dir-remote/hw/virtio/virtio.c:994 req=req@entry=0xaaaaf620aa30, status=status@entry=0 '\000') at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:67 ret=0) at ../qemu-xen-dir-remote/hw/block/virtio-blk.c:136 at ../qemu-xen-dir-remote/block/block-backend.c:1559 --Type <RET> for more, q to quit, c to continue without paging-- at ../qemu-xen-dir-remote/block/block-backend.c:1614 i1=<optimized out>) at ../qemu-xen-dir-remote/util/coroutine-ucontext.c:177 at ../sysdeps/unix/sysv/linux/aarch64/setcontext.S:123 Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <20240124021450.21656-1-peng.fan@oss.nxp.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> (cherry picked from commit 9253d83062268209533df4b29859e5b51a2dc324) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 13 March 2024, 17:15:59 UTC |
| 31e2069 | Nick Briggs | 01 February 2024, 18:11:17 UTC | Avoid unaligned fetch in ladr_match() There is no guarantee that the PCNetState is allocated such that csr[8] is allocated on an 8-byte boundary. Since not all hosts are capable of unaligned fetches the 16-bit elements need to be fetched individually to avoid a potential fault. Closes issue #2143 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2143 Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 6a5287ce80470bb8df95901d73ee779a64e70c3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 12 March 2024, 17:51:32 UTC |
| 0ba8be8 | Laurent Vivier | 24 January 2024, 10:40:06 UTC | e1000e: fix link state on resume On resume e1000e_vm_state_change() always calls e1000e_autoneg_resume() that sets link_down to false, and thus activates the link even if we have disabled it. The problem can be reproduced starting qemu in paused state (-S) and then set the link to down. When we resume the machine the link appears to be up. Reproducer: # qemu-system-x86_64 ... -device e1000e,netdev=netdev0,id=net0 -S {"execute": "qmp_capabilities" } {"execute": "set_link", "arguments": {"name": "net0", "up": false}} {"execute": "cont" } To fix the problem, merge the content of e1000e_vm_state_change() into e1000e_core_post_load() as e1000 does. Buglink: https://issues.redhat.com/browse/RHEL-21867 Fixes: 6f3fbe4ed06a ("net: Introduce e1000e device emulation") Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 4cadf10234989861398e19f3bb441d3861f3bb7c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 12 March 2024, 17:50:43 UTC |
| c440c89 | Laurent Vivier | 24 January 2024, 10:29:03 UTC | igb: fix link state on resume On resume igb_vm_state_change() always calls igb_autoneg_resume() that sets link_down to false, and thus activates the link even if we have disabled it. The problem can be reproduced starting qemu in paused state (-S) and then set the link to down. When we resume the machine the link appears to be up. Reproducer: # qemu-system-x86_64 ... -device igb,netdev=netdev0,id=net0 -S {"execute": "qmp_capabilities" } {"execute": "set_link", "arguments": {"name": "net0", "up": false}} {"execute": "cont" } To fix the problem, merge the content of igb_vm_state_change() into igb_core_post_load() as e1000 does. Buglink: https://issues.redhat.com/browse/RHEL-21867 Fixes: 3a977deebe6b ("Intrdocue igb device emulation") Cc: akihiko.odaki@daynix.com Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 65c2ab808571dcd9322020690a63df63281a67f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 12 March 2024, 17:50:43 UTC |
| 6ad78a0 | Yu Zhang | 06 March 2024, 08:06:54 UTC | migration/rdma: Fix a memory issue for migration In commit 3fa9642ff7 change was made to convert the RDMA backend to accept MigrateAddress struct. However, the assignment of "host" leads to data corruption on the target host and the failure of migration. isock->host = rdma->host; By allocating the memory explicitly for it with g_strdup_printf(), the issue is fixed and the migration doesn't fail any more. Fixes: 3fa9642ff7 ("migration: convert rdma backend to accept MigrateAddress") Cc: qemu-stable <qemu-stable@nongnu.org> Cc: Li Zhijian <lizhijian@fujitsu.com> Link: https://lore.kernel.org/r/CAHEcVy4L_D6tuhJ8h=xLR4WaPaprJE3nnxZAEyUnoTrxQ6CF5w@mail.gmail.com Signed-off-by: Yu Zhang <yu.zhang@ionos.com> [peterx: use g_strdup() instead of g_strdup_printf(), per Zhijian] Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 69f7b00d057f8832a841a53d5ee31eb303157398) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 12 March 2024, 17:43:32 UTC |
| 8f1eb52 | Michael Tokarev | 04 March 2024, 18:46:39 UTC | make-release: switch to .xz format by default For a long time, we provide two compression formats in the download area, .bz2 and .xz. There's absolutely no reason to provide two in parallel, .xz compresses better, and all the links we use points to .xz. Downstream distributions mostly use .xz too. For the release maintenance providing two formats is definitely extra burden too. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 9bc9e95119445d7a430b0fc8b7daf22a3612bbd3) | 10 March 2024, 15:37:11 UTC |
| 5ae5473 | Sven Schnelle | 29 February 2024, 20:44:07 UTC | hw/scsi/lsi53c895a: add timer to scripts processing HP-UX 10.20 seems to make the lsi53c895a spinning on a memory location under certain circumstances. As the SCSI controller and CPU are not running at the same time this loop will never finish. After some time, the check loop interrupts with a unexpected device disconnect. This works, but is slow because the kernel resets the scsi controller. Instead of signaling UDC, start a timer and exit the loop. Until the timer fires, the CPU can process instructions which might changes the memory location. The limit of instructions is also reduced because scripts running on the SCSI processor are usually very short. This keeps the time until the loop is exit short. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Sven Schnelle <svens@stackframe.org> Message-ID: <20240229204407.1699260-1-svens@stackframe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9876359990dd4c8a48de65cf5e1c3d13e96a7f4e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 10 March 2024, 15:29:04 UTC |
| 37a8b92 | Sven Schnelle | 02 March 2024, 21:44:53 UTC | hw/scsi/lsi53c895a: stop script on phase mismatch Netbsd isn't happy with qemu lsi53c895a emulation: cd0(esiop0:0:2:0): command with tag id 0 reset esiop0: autoconfiguration error: phase mismatch without command esiop0: autoconfiguration error: unhandled scsi interrupt, sist=0x80 sstat1=0x0 DSA=0x23a64b1 DSP=0x50 This is because lsi_bad_phase() triggers a phase mismatch, which stops SCRIPT processing. However, after returning to lsi_command_complete(), SCRIPT is restarted with lsi_resume_script(). Fix this by adding a return value to lsi_bad_phase(), and only resume script processing when lsi_bad_phase() didn't trigger a host interrupt. Signed-off-by: Sven Schnelle <svens@stackframe.org> Tested-by: Helge Deller <deller@gmx.de> Message-ID: <20240302214453.2071388-1-svens@stackframe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a9198b3132d81a6bfc9fdbf6f3d3a514c2864674) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 10 March 2024, 09:29:44 UTC |
| 5dc46b3 | Dmitrii Gavrilov | 03 November 2023, 10:56:02 UTC | system/qdev-monitor: move drain_call_rcu call under if (!dev) in qmp_device_add() Original goal of addition of drain_call_rcu to qmp_device_add was to cover the failure case of qdev_device_add. It seems call of drain_call_rcu was misplaced in 7bed89958bfbf40df what led to waiting for pending RCU callbacks under happy path too. What led to overall performance degradation of qmp_device_add. In this patch call of drain_call_rcu moved under handling of failure of qdev_device_add. Signed-off-by: Dmitrii Gavrilov <ds-gavr@yandex-team.ru> Message-ID: <20231103105602.90475-1-ds-gavr@yandex-team.ru> Fixes: 7bed89958bf ("device_core: use drain_call_rcu in in qmp_device_add", 2020-10-12) Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 012b170173bcaa14b9bc26209e0813311ac78489) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 10 March 2024, 09:25:05 UTC |
| 4db9340 | Peter Maydell | 23 February 2024, 16:13:00 UTC | hw/rtc/sun4v-rtc: Relicense to GPLv2-or-later The sun4v RTC device model added under commit a0e893039cf2ce0 in 2016 was unfortunately added with a license of GPL-v3-or-later, which is not compatible with other QEMU code which has a GPL-v2-only license. Relicense the code in the .c and the .h file to GPL-v2-or-later, to make it compatible with the rest of QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini (for Red Hat) <pbonzini@redhat.com> Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240223161300.938542-1-peter.maydell@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit fd7f95f23d6fe485332c1d4b489eb719fcb7c225) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 09 March 2024, 18:42:00 UTC |
| f0ae5d6 | Richard Henderson | 05 March 2024, 16:39:31 UTC | target/arm: Fix 32-bit SMOPA While the 8-bit input elements are sequential in the input vector, the 32-bit output elements are not sequential in the output matrix. Do not attempt to compute 2 32-bit outputs at the same time. Cc: qemu-stable@nongnu.org Fixes: 23a5e3859f5 ("target/arm: Implement SME integer outer product") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2083 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240305163931.242795-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit d572bcb222010b38b382871a23b2f38e2c3f4d2d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 09 March 2024, 16:01:05 UTC |
| 81c0ebf | David Parsons | 24 February 2024, 14:06:20 UTC | ui/cocoa: Fix window clipping on macOS 14 macOS Sonoma changes the NSView.clipsToBounds to false by default where it was true in earlier version of macOS. This causes the window contents to be occluded by the frame at the top of the window. This fixes the issue by conditionally compiling the clipping on Sonoma to true. NSView only exposes the clipToBounds in macOS 14 and so has to be fixed via conditional compilation. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1994 Signed-off-by: David Parsons <dave@daveparsons.net> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-ID: <20240224140620.39200-1-dave@daveparsons.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit f5af80271aad356233b2bea2369b3b2211fa395d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 09 March 2024, 15:59:33 UTC |
| 94b544f | Daniel P. Berrangé | 04 March 2024, 14:44:56 UTC | gitlab: update FreeBSD Cirrus CI image to 13.3 The 13.2 images have been deleted from gcloud Cc: qemu-stable@nongnu.org Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240304144456.3825935-3-berrange@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 9ea920dc28254cd9a363aaef01985dffd8abedd7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 05 March 2024, 14:46:29 UTC |
| 420a8d8 | Richard Henderson | 14 February 2024, 04:18:01 UTC | linux-user: Remove pgb_dynamic alignment assertion The assertion was never correct, because the alignment is a composite of the image alignment and SHMLBA. Even if the image alignment didn't match the image address, an assertion would not be correct -- more appropriate would be an error message about an ill formed image. But the image cannot be held to SHMLBA under any circumstances. Fixes: ee94743034b ("linux-user: completely re-write init_guest_space") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2157 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reported-by: Alexey Sheplyakov <asheplyakov@yandex.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit b816e1b5ba58a986b10cd830d6617f351979ab91) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 05 March 2024, 14:41:31 UTC |
| 151d593 | Richard Henderson | 16 February 2024, 21:40:11 UTC | tcg/aarch64: Apple does not align __int128_t in even registers From https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms When passing an argument with 16-byte alignment in integer registers, Apple platforms allow the argument to start in an odd-numbered xN register. The standard ABI requires it to begin in an even-numbered xN register. Cc: qemu-stable@nongnu.org Fixes: 5427a9a7604 ("tcg: Add TCG_TARGET_CALL_{RET,ARG}_I128") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2169 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <9fc0c2c7-dd57-459e-aecb-528edb74b4a7@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 7f89fdf8ebe6ef8df48f0a05f44e1020c713a94e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 05 March 2024, 14:38:26 UTC |
| 16f1f95 | Paolo Bonzini | 07 February 2024, 16:38:01 UTC | configure: run plugin TCG tests again Commit 39fb3cfc28b ("configure: clean up plugin option handling", 2023-10-18) dropped the CONFIG_PLUGIN line from tests/tcg/config-host.mak, due to confusion caused by the shadowing of $config_host_mak. However, TCG tests were still expecting it. Oops. Put it back, in the meanwhile the shadowing is gone so it's clear that it goes in the tests/tcg configuration. Cc: <alex.bennee@linaro.org> Fixes: 39fb3cfc28b ("configure: clean up plugin option handling", 2023-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20240124115332.612162-1-pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240207163812.3231697-4-alex.bennee@linaro.org> (cherry picked from commit 15cc103362499bd94c5aec5fa66543d0de3bf4b5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup for 8.2.x - $config_host_mak without tests/tcg/ prefix - for before v8.2.0-142-g606c3ba7a2 "configure: remove unnecessary subshell") | 04 March 2024, 21:44:20 UTC |
| eae7509 | Michael Tokarev | 04 March 2024, 21:30:36 UTC | Revert "configure: run plugin TCG tests again" This reverts commit 6eeeb8733177db7bc23fb2e7271dea759b47e4f9. This commit has been wrongly back-ported to 8.2.x, $config_host_mak in master didn't include the tests/tcg/ prefix, while 8.2.0 did it. The result of this "backport" is this message during configure: ../configure: 1679: cannot create tests/tcg/tests/tcg/config-host.mak: Directory nonexistent Let's revert the change and try again. Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 04 March 2024, 21:42:22 UTC |
| 11aa0b1 | Michael Tokarev | 04 March 2024, 12:15:46 UTC | Update version for 8.2.2 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 04 March 2024, 12:15:46 UTC |
| 2121469 | Thomas Huth | 29 February 2024, 10:43:37 UTC | chardev/char-socket: Fix TLS io channels sending too much data to the backend Commit ffda5db65a ("io/channel-tls: fix handling of bigger read buffers") changed the behavior of the TLS io channels to schedule a second reading attempt if there is still incoming data pending. This caused a regression with backends like the sclpconsole that check in their read function that the sender does not try to write more bytes to it than the device can currently handle. The problem can be reproduced like this: 1) In one terminal, do this: mkdir qemu-pki cd qemu-pki openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem # enter some dummy value for the cert openssl genrsa 2048 > server-key.pem openssl req -new -x509 -nodes -days 365000 -key server-key.pem \ -out server-cert.pem # enter some other dummy values for the cert gnutls-serv --echo --x509cafile ca-cert.pem --x509keyfile server-key.pem \ --x509certfile server-cert.pem -p 8338 2) In another terminal, do this: wget https://download.fedoraproject.org/pub/fedora-secondary/releases/39/Cloud/s390x/images/Fedora-Cloud-Base-39-1.5.s390x.qcow2 qemu-system-s390x -nographic -nodefaults \ -hda Fedora-Cloud-Base-39-1.5.s390x.qcow2 \ -object tls-creds-x509,id=tls0,endpoint=client,verify-peer=false,dir=$PWD/qemu-pki \ -chardev socket,id=tls_chardev,host=localhost,port=8338,tls-creds=tls0 \ -device sclpconsole,chardev=tls_chardev,id=tls_serial QEMU then aborts after a second or two with: qemu-system-s390x: ../hw/char/sclpconsole.c:73: chr_read: Assertion `size <= SIZE_BUFFER_VT220 - scon->iov_data_len' failed. Aborted (core dumped) It looks like the second read does not trigger the chr_can_read() function to be called before the second read, which should normally always be done before sending bytes to a character device to see how much it can handle, so the s->max_size in tcp_chr_read() still contains the old value from the previous read. Let's make sure that we use the up-to-date value by calling tcp_chr_read_poll() again here. Fixes: ffda5db65a ("io/channel-tls: fix handling of bigger read buffers") Buglink: https://issues.redhat.com/browse/RHEL-24614 Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com> Message-ID: <20240229104339.42574-1-thuth@redhat.com> Reviewed-by: Antoine Damhet <antoine.damhet@blade-group.com> Tested-by: Antoine Damhet <antoine.damhet@blade-group.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 462945cd22d2bcd233401ed3aa167d83a8e35b05) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 01 March 2024, 16:02:35 UTC |
| 2a97c05 | Thomas Huth | 26 February 2024, 08:27:28 UTC | tests/unit/test-util-sockets: Remove temporary file after test test-util-sockets leaves the temporary socket files around in the temporary files folder. Let's better remove them at the end of the testing. Fixes: 4d3a329af5 ("tests/util-sockets: add abstract unix socket cases") Message-ID: <20240226082728.249753-1-thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit f0cb6828ae34fb56fbb869bb3147a636d1c984ce) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 01 March 2024, 16:00:11 UTC |
| e6ce551 | Benjamin David Lunt | 25 February 2024, 19:49:51 UTC | hw/usb/bus.c: PCAP adding 0xA in Windows version Since Windows text files use CRLFs for all \n, the Windows version of QEMU inserts a CR in the PCAP stream when a LF is encountered when using USB PCAP files. This is due to the fact that the PCAP file is opened as TEXT instead of BINARY. To show an example, when using a very common protocol to USB disks, the BBB protocol uses a 10-byte command packet. For example, the READ_CAPACITY(10) command will have a command block length of 10 (0xA). When this 10-byte command (part of the 31-byte CBW) is placed into the PCAP file, the Windows file manager inserts a 0xD before the 0xA, turning the 31-byte CBW into a 32-byte CBW. Actual CBW: 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0a 25 USBC...........% 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... PCAP CBW 0040 55 53 42 43 01 00 00 00 08 00 00 00 80 00 0d 0a USBC............ 0050 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %.............. I believe simply opening the PCAP file as BINARY instead of TEXT will fix this issue. Resolves: https://bugs.launchpad.net/qemu/+bug/2054889 Signed-off-by: Benjamin David Lunt <benlunt@fysnet.net> Message-ID: <000101da6823$ce1bbf80$6a533e80$@fysnet.net> [thuth: Break long line to avoid checkpatch.pl error] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 5e02a4fdebc442e34c5bb05e4540f85cc6e802f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 01 March 2024, 15:59:21 UTC |
| 829bb27 | Thomas Huth | 21 February 2024, 11:00:59 UTC | hw/intc/Kconfig: Fix GIC settings when using "--without-default-devices" When using "--without-default-devices", the ARM_GICV3_TCG and ARM_GIC_KVM settings currently get disabled, though the arm virt machine is only of very limited use in that case. This also causes the migration-test to fail in such builds. Let's make sure that we always keep the GIC switches enabled in the --without-default-devices builds, too. Message-ID: <20240221110059.152665-1-thuth@redhat.com> Tested-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8bd3f84d1f6fba0edebc450be6fa2c7630584df9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 01 March 2024, 15:59:06 UTC |
| 0e33e4e | Daniel P. Berrangé | 22 February 2024, 11:40:38 UTC | gitlab: force allow use of pip in Cirrus jobs Python is transitioning to a world where you're not allowed to use 'pip install' outside of a virutal env by default. The rationale is to stop use of pip clashing with distro provided python packages, which creates a major headache on distro upgrades. All our CI environments, however, are 100% disposable so the upgrade headaches don't exist. Thus we can undo the python defaults to allow pip to work. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20240222114038.2348718-1-berrange@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a8bf9de2f4f398315ac5340e4b88c478d5457731) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 21:00:21 UTC |
| 6c14f93 | Alex Bennée | 27 February 2024, 14:43:09 UTC | tests/vm: avoid re-building the VM images all the time The main problem is that "check-venv" is a .PHONY target will always evaluate and trigger a full re-build of the VM images. While its tempting to drop it from the dependencies that does introduce a breakage on freshly configured builds. Fortunately we do have the otherwise redundant --force flag for the script which up until now was always on. If we make the usage of --force conditional on dependencies other than check-venv triggering the update we can avoid the costly rebuild and still run cleanly on a fresh checkout. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2118 Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-4-alex.bennee@linaro.org> (cherry picked from commit 151b7dba391fab64cc008a1fdba6ddcf6f8c39c8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:21:04 UTC |
| 36d50b4 | Alex Bennée | 27 February 2024, 14:43:10 UTC | tests/vm: update openbsd image to 7.4 The old links are dead so even if we have the ISO cached we can't finish the install. Update to the current stable and tweak the install strings. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2192 Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-5-alex.bennee@linaro.org> (cherry picked from commit 8467ac75b3b7207a49a1c6c7b87f0f7d2d0cea18) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:20:12 UTC |
| decafac | Paolo Bonzini | 22 December 2023, 08:48:35 UTC | target/i386: leave the A20 bit set in the final NPT walk The A20 mask is only applied to the final memory access. Nested page tables are always walked with the raw guest-physical address. Unlike the previous patch, in this one the masking must be kept, but it was done too early. Cc: qemu-stable@nongnu.org Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b5a9de3259f4c791bde2faff086dd5737625e41e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:19:03 UTC |
| 6801a20 | Paolo Bonzini | 22 December 2023, 08:52:27 UTC | target/i386: remove unnecessary/wrong application of the A20 mask If ptw_translate() does a MMU_PHYS_IDX access, the A20 mask is already applied in get_physical_address(), which is called via probe_access_full() and x86_cpu_tlb_fill(). If ptw_translate() on the other hand does a MMU_NESTED_IDX access, the A20 mask must not be applied to the address that is looked up in the nested page tables; it must be applied only to the addresses that hold the NPT entries (which is achieved via MMU_PHYS_IDX, per the previous paragraph). Therefore, we can remove A20 masking from the computation of the page table entry's address, and let get_physical_address() or mmu_translate() apply it when they know they are returning a host-physical address. Cc: qemu-stable@nongnu.org Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a28fe7dc1939333c81b895cdced81c69eb7c5ad0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:18:45 UTC |
| a28b6b4 | Paolo Bonzini | 22 December 2023, 17:01:52 UTC | target/i386: Fix physical address truncation The address translation logic in get_physical_address() will currently truncate physical addresses to 32 bits unless long mode is enabled. This is incorrect when using physical address extensions (PAE) outside of long mode, with the result that a 32-bit operating system using PAE to access memory above 4G will experience undefined behaviour. The truncation code was originally introduced in commit 33dfdb5 ("x86: only allow real mode to access 32bit without LMA"), where it applied only to translations performed while paging is disabled (and so cannot affect guests using PAE). Commit 9828198 ("target/i386: Add MMU_PHYS_IDX and MMU_NESTED_IDX") rearranged the code such that the truncation also applied to the use of MMU_PHYS_IDX and MMU_NESTED_IDX. Commit 4a1e9d4 ("target/i386: Use atomic operations for pte updates") brought this truncation into scope for page table entry accesses, and is the first commit for which a Windows 10 32-bit guest will reliably fail to boot if memory above 4G is present. The truncation code however is not completely redundant. Even though the maximum address size for any executed instruction is 32 bits, helpers for operations such as BOUND, FSAVE or XSAVE may ask get_physical_address() to translate an address outside of the 32-bit range, if invoked with an argument that is close to the 4G boundary. Likewise for processor accesses, for example TSS or IDT accesses, when EFER.LMA==0. So, move the address truncation in get_physical_address() so that it applies to 32-bit MMU indexes, but not to MMU_PHYS_IDX and MMU_NESTED_IDX. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2040 Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Cc: qemu-stable@nongnu.org Co-developed-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b1661801c184119a10ad6cbc3b80330fc22e7b2c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop unrelated change in target/i386/cpu.c) | 28 February 2024, 18:15:46 UTC |
| 5c4091f | Paolo Bonzini | 22 December 2023, 16:47:38 UTC | target/i386: check validity of VMCB addresses MSR_VM_HSAVE_PA bits 0-11 are reserved, as are the bits above the maximum physical address width of the processor. Setting them to 1 causes a #GP (see "15.30.4 VM_HSAVE_PA MSR" in the AMD manual). The same is true of VMCB addresses passed to VMRUN/VMLOAD/VMSAVE, even though the manual is not clear on that. Cc: qemu-stable@nongnu.org Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit d09c79010ffd880dc69e7a21e3cfdef90b928fb8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:03:19 UTC |
| 6ed8211 | Paolo Bonzini | 22 December 2023, 08:27:36 UTC | target/i386: mask high bits of CR3 in 32-bit mode CR3 bits 63:32 are ignored in 32-bit mode (either legacy 2-level paging or PAE paging). Do this in mmu_translate() to remove the last where get_physical_address() meaningfully drops the high bits of the address. Cc: qemu-stable@nongnu.org Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: 4a1e9d4d11c ("target/i386: Use atomic operations for pte updates", 2022-10-18) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 68fb78d7d5723066ec2cacee7d25d67a4143b42f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 28 February 2024, 18:02:56 UTC |
| a0fb839 | Jessica Clarke | 26 February 2024, 14:07:24 UTC | pl031: Update last RTCLR value on write in case it's read back The PL031 allows you to read RTCLR, which is meant to give you the last value written. PL031State has an lr field which is used when reading from RTCLR, and is present in the VM migration state, but we never actually update it, so it always reads as its initial 0 value. Cc: qemu-stable@nongnu.org Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240222000341.1562443-1-jrtc27@jrtc27.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4d28d57c9f2eb1cdf70b29cea6e50282e010075b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 February 2024, 17:37:06 UTC |
| e4e36e6 | Klaus Jensen | 22 February 2024, 09:29:06 UTC | hw/nvme: fix invalid endian conversion numcntl is one byte and so is max_vfs. Using cpu_to_le16 on big endian hosts results in numcntl being set to 0. Fix by dropping the endian conversion. Fixes: 99f48ae7ae ("hw/nvme: Add support for Secondary Controller List") Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> Reviewed-by: Minwoo Im <minwoo.im@samsung.com> Message-ID: <20240222-fix-sriov-numcntl-v1-1-d60bea5e72d0@samsung.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit d2b5bb860e6c17442ad95cc275feb07c1665be5c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 February 2024, 16:14:41 UTC |
| 8c86c88 | Gerd Hoffmann | 26 February 2024, 09:23:25 UTC | update edk2 binaries to edk2-stable202402 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 658178c3d4e95b3f4106e25ec5a209356e339032) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 February 2024, 11:05:06 UTC |
| cc98bd4 | Gerd Hoffmann | 26 February 2024, 09:08:33 UTC | update edk2 submodule to edk2-stable202402 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 9c996f3d11f8582ac5d4daf5d17453ac09d4acf8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 27 February 2024, 11:05:06 UTC |
| 131ed62 | Nicholas Piggin | 15 December 2023, 08:58:49 UTC | target/ppc: Fix crash on machine check caused by ifetch is_prefix_insn_excp() loads the first word of the instruction address which caused an exception, to determine whether or not it was prefixed so the prefix bit can be set in [H]SRR1. This works if the instruction image can be loaded, but if the exception was caused by an ifetch, this load could fail and cause a recursive exception and crash. Machine checks caused by ifetch are not excluded from the prefix check and can crash (see issue 2108 for an example). Fix this by excluding machine checks caused by ifetch from the prefix check. Cc: qemu-stable@nongnu.org Acked-by: Cédric Le Goater <clg@kaod.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2108 Fixes: 55a7fa34f89 ("target/ppc: Machine check on invalid real address access on POWER9/10") Fixes: 5a5d3b23cb2 ("target/ppc: Add SRR1 prefix indication to interrupt handlers") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit c8fd9667e5975fe2e70a906e125a758737eab707) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 24 February 2024, 16:29:45 UTC |
| 175bded | Nicholas Piggin | 13 February 2024, 07:50:43 UTC | target/ppc: Fix lxv/stxv MSR facility check The move to decodetree flipped the inequality test for the VEC / VSX MSR facility check. This caused application crashes under Linux, where these facility unavailable interrupts are used for lazy-switching of VEC/VSX register sets. Getting the incorrect interrupt would result in wrong registers being loaded, potentially overwriting live values and/or exposing stale ones. Cc: qemu-stable@nongnu.org Reported-by: Joel Stanley <joel@jms.id.au> Fixes: 70426b5bb738 ("target/ppc: moved stxvx and lxvx from legacy to decodtree") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1769 Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Tested-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit 2cc0e449d17310877fb28a942d4627ad22bb68ea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 24 February 2024, 16:29:11 UTC |
| 01aa603 | Peter Maydell | 20 February 2024, 16:56:02 UTC | .gitlab-ci.d/windows.yml: Drop msys2-32bit job MSYS2 is dropping support for 32-bit Windows. This shows up for us as various packages we were using in our CI job no longer being available to install, which causes the job to fail. In commit 8e31b744fdf we dropped the dependency on libusb and spice, but the dtc package has also now been removed. For us as QEMU upstream, "32 bit x86 hosts for system emulation" have already been deprecated as of QEMU 8.0, so we are ready to drop them anyway. Drop the msys2-32bit CI job, as the first step in doing this. This is cc'd to stable, because this job will also be broken for CI on the stable branches. We can't drop 32-bit support entirely there, but we will still be covering at least compilation for 32-bit Windows via the cross-win32-system job. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240220165602.135695-1-peter.maydell@linaro.org (cherry picked from commit 5cd3ae4903e33982e7a9bbd04674af517e796d6e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 February 2024, 15:46:16 UTC |
| aafe8c0 | Tianlan Zhou | 21 February 2024, 19:52:10 UTC | system/vl: Update description for input grab key Input grab key should be Ctrl-Alt-g, not just Ctrl-Alt. Fixes: f8d2c9369b ("sdl: use ctrl-alt-g as grab hotkey") Signed-off-by: Tianlan Zhou <bobby825@126.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 185311130f54ead75c407cdf83004d575829b5d2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 February 2024, 15:46:06 UTC |
| 2da2e67 | Tianlan Zhou | 21 February 2024, 19:52:09 UTC | docs/system: Update description for input grab key Input grab key should be Ctrl-Alt-g, not just Ctrl-Alt. Fixes: f8d2c9369b ("sdl: use ctrl-alt-g as grab hotkey") Signed-off-by: Tianlan Zhou <bobby825@126.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 4a20ac400ff0753f159071764826b20e5320cde9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 February 2024, 15:46:06 UTC |
| 56ee4a6 | Thomas Huth | 16 February 2024, 09:16:21 UTC | hw/hppa/Kconfig: Fix building with "configure --without-default-devices" When running "configure" with "--without-default-devices", building of qemu-system-hppa currently fails with: /usr/bin/ld: libqemu-hppa-softmmu.fa.p/hw_hppa_machine.c.o: in function `machine_HP_common_init_tail': hw/hppa/machine.c:399: undefined reference to `usb_bus_find' /usr/bin/ld: hw/hppa/machine.c:399: undefined reference to `usb_create_simple' /usr/bin/ld: hw/hppa/machine.c:400: undefined reference to `usb_bus_find' /usr/bin/ld: hw/hppa/machine.c:400: undefined reference to `usb_create_simple' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. make: *** [Makefile:162: run-ninja] Error 1 And after fixing this, the qemu-system-hppa binary refuses to run due to the missing 'pci-ohci' and 'pci-serial' devices. Let's add the right config switches to fix these problems. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 04b86ccb5dc8a1fad809753cfbaafd4bb13283d4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 22 February 2024, 15:45:41 UTC |
| 814f887 | Akihiko Odaki | 14 February 2024, 14:03:58 UTC | tests/qtest: Depend on dbus_display1_dep It ensures dbus-display1.c will not be recompiled. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20240214-dbus-v7-3-7eff29f04c34@daynix.com> (cherry picked from commit 186acfbaf7f325833702f50f75ef5116dc29e233) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 16:01:51 UTC |
| fb22ee7 | Akihiko Odaki | 14 February 2024, 14:03:57 UTC | meson: Explicitly specify dbus-display1.h dependency Explicitly specify dbus-display1.h as a dependency so that files depending on it will not get compiled too early. Fixes: 1222070e7728 ("meson: ensure dbus-display generated code is built before other units") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20240214-dbus-v7-2-7eff29f04c34@daynix.com> (cherry picked from commit 7aee57df930da2cf6361c5183aff96468ae4027d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 16:01:32 UTC |
| 1766b93 | Akihiko Odaki | 14 February 2024, 14:03:56 UTC | audio: Depend on dbus_display1_dep dbusaudio needs dbus_display1_dep. Fixes: 739362d4205c ("audio: add "dbus" audio backend") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20240214-dbus-v7-1-7eff29f04c34@daynix.com> (cherry picked from commit d67611907590a1e6c998b7c5a5cb4394acf84329) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:55:19 UTC |
| 2e5c9d5 | Tianlan Zhou | 07 February 2024, 17:20:25 UTC | ui/console: Fix console resize with placeholder surface In `qemu_console_resize()`, the old surface of the console is keeped if the new console size is the same as the old one. If the old surface is a placeholder, and the new size of console is the same as the placeholder surface (640*480), the surface won't be replace. In this situation, the surface's `QEMU_PLACEHOLDER_FLAG` flag is still set, so the console won't be displayed in SDL display mode. This patch fixes this problem by forcing a new surface if the old one is a placeholder. Signed-off-by: Tianlan Zhou <bobby825@126.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20240207172024.8-1-bobby825@126.com> (cherry picked from commit 95b08fee8f68d284a5028d37fd28be7a70c8e92b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:49:44 UTC |
| 7ff0d4d | Fiona Ebner | 24 January 2024, 10:57:49 UTC | ui/clipboard: add asserts for update and request Should an issue like CVE-2023-6683 ever appear again in the future, it will be more obvious which assumption was violated. Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20240124105749.204610-2-f.ebner@proxmox.com> (cherry picked from commit 9c416582611b7495bdddb4c5456c7acb64b78938) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:49:10 UTC |
| 480a6ad | Fiona Ebner | 24 January 2024, 10:57:48 UTC | ui/clipboard: mark type as not available when there is no data With VNC, a client can send a non-extended VNC_MSG_CLIENT_CUT_TEXT message with len=0. In qemu_clipboard_set_data(), the clipboard info will be updated setting data to NULL (because g_memdup(data, size) returns NULL when size is 0). If the client does not set the VNC_ENCODING_CLIPBOARD_EXT feature when setting up the encodings, then the 'request' callback for the clipboard peer is not initialized. Later, because data is NULL, qemu_clipboard_request() can be reached via vdagent_chr_write() and vdagent_clipboard_recv_request() and there, the clipboard owner's 'request' callback will be attempted to be called, but that is a NULL pointer. In particular, this can happen when using the KRDC (22.12.3) VNC client. Another scenario leading to the same issue is with two clients (say noVNC and KRDC): The noVNC client sets the extension VNC_FEATURE_CLIPBOARD_EXT and initializes its cbpeer. The KRDC client does not, but triggers a vnc_client_cut_text() (note it's not the _ext variant)). There, a new clipboard info with it as the 'owner' is created and via qemu_clipboard_set_data() is called, which in turn calls qemu_clipboard_update() with that info. In qemu_clipboard_update(), the notifier for the noVNC client will be called, i.e. vnc_clipboard_notify() and also set vs->cbinfo for the noVNC client. The 'owner' in that clipboard info is the clipboard peer for the KRDC client, which did not initialize the 'request' function. That sounds correct to me, it is the owner of that clipboard info. Then when noVNC sends a VNC_MSG_CLIENT_CUT_TEXT message (it did set the VNC_FEATURE_CLIPBOARD_EXT feature correctly, so a check for it passes), that clipboard info is passed to qemu_clipboard_request() and the original segfault still happens. Fix the issue by handling updates with size 0 differently. In particular, mark in the clipboard info that the type is not available. While at it, switch to g_memdup2(), because g_memdup() is deprecated. Cc: qemu-stable@nongnu.org Fixes: CVE-2023-6683 Reported-by: Markus Frank <m.frank@proxmox.com> Suggested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Markus Frank <m.frank@proxmox.com> Message-ID: <20240124105749.204610-1-f.ebner@proxmox.com> (cherry picked from commit 405484b29f6548c7b86549b0f961b906337aa68a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:45:27 UTC |
| 4fd56da | Daniel P. Berrangé | 15 January 2024, 09:51:19 UTC | ui: reject extended clipboard message if not activated The extended clipboard message protocol requires that the client activate the extension by requesting a psuedo encoding. If this is not done, then any extended clipboard messages from the client should be considered invalid and the client dropped. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20240115095119.654271-1-berrange@redhat.com> (cherry picked from commit 4cba8388968b70fe20e290221dc421c717051fdd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:45:20 UTC |
| 0b30735 | Ziqiao Kong | 15 February 2024, 09:50:17 UTC | target/i386: Generate an illegal opcode exception on cmp instructions with lock prefix target/i386: As specified by Intel Manual Vol2 3-180, cmp instructions are not allowed to have lock prefix and a `UD` should be raised. Without this patch, s1->T0 will be uninitialized and used in the case OP_CMPL. Signed-off-by: Ziqiao Kong <ziqiaokong@gmail.com> Message-ID: <20240215095015.570748-2-ziqiaokong@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 99d0dcd7f102c07a510200d768cae65e5db25d23) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:44:21 UTC |
| f5dddb8 | Xiaoyao Li | 25 January 2024, 02:40:16 UTC | i386/cpuid: Move leaf 7 to correct group CPUID leaf 7 was grouped together with SGX leaf 0x12 by commit b9edbadefb9e ("i386: Propagate SGX CPUID sub-leafs to KVM") by mistake. SGX leaf 0x12 has its specific logic to check if subleaf (starting from 2) is valid or not by checking the bit 0:3 of corresponding EAX is 1 or not. Leaf 7 follows the logic that EAX of subleaf 0 enumerates the maximum valid subleaf. Fixes: b9edbadefb9e ("i386: Propagate SGX CPUID sub-leafs to KVM") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-ID: <20240125024016.2521244-4-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0729857c707535847d7fe31d3d91eb8b2a118e3c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:43:03 UTC |
| e8d2772 | Xiaoyao Li | 25 January 2024, 02:40:14 UTC | i386/cpuid: Decrease cpuid_i when skipping CPUID leaf 1F Existing code misses a decrement of cpuid_i when skip leaf 0x1F. There's a blank CPUID entry(with leaf, subleaf as 0, and all fields stuffed 0s) left in the CPUID array. It conflicts with correct CPUID leaf 0. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by:Yang Weijiang <weijiang.yang@intel.com> Message-ID: <20240125024016.2521244-2-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 10f92799af8ba3c3cef2352adcd4780f13fbab31) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:42:24 UTC |
| 72c4ef9 | Xiaoyao Li | 15 January 2024, 09:13:25 UTC | i386/cpu: Mask with XCR0/XSS mask for FEAT_XSAVE_XCR0_HI and FEAT_XSAVE_XSS_HI leafs The value of FEAT_XSAVE_XCR0_HI leaf and FEAT_XSAVE_XSS_HI leaf also need to be masked by XCR0 and XSS mask respectively, to make it logically correct. Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Yang Weijiang <weijiang.yang@intel.com> Message-ID: <20240115091325.1904229-3-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a11a365159b944e05be76f3ec3b98c8b38cb70fd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:41:43 UTC |
| 0766f13 | Xiaoyao Li | 15 January 2024, 09:13:24 UTC | i386/cpu: Clear FEAT_XSAVE_XSS_LO/HI leafs when CPUID_EXT_XSAVE is not available Leaf FEAT_XSAVE_XSS_LO and FEAT_XSAVE_XSS_HI also need to be cleared when CPUID_EXT_XSAVE is not set. Fixes: 301e90675c3f ("target/i386: Enable support for XSAVES based features") Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Yang Weijiang <weijiang.yang@intel.com> Message-ID: <20240115091325.1904229-2-xiaoyao.li@intel.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 81f5cad3858f27623b1b14467926032d229b76cc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 20 February 2024, 15:41:25 UTC |
| 4d9dc11 | Peter Maydell | 15 February 2024, 15:50:09 UTC | .gitlab-ci/windows.yml: Don't install libusb or spice packages on 32-bit When msys2 updated their libusb packages to libusb 1.0.27, they dropped support for building them for mingw32, leaving only mingw64 packages. This broke our CI job, as the 'pacman' package install now fails with: error: target not found: mingw-w64-i686-libusb error: target not found: mingw-w64-i686-usbredir (both these binary packages are from the libusb source package). Similarly, spice is now 64-bit only: error: target not found: mingw-w64-i686-spice Fix this by dropping these packages from the list we install for our msys2-32bit build. We do this with a simple mechanism for the msys2-64bit and msys2-32bit jobs to specify a list of extra packages to install on top of the common ones we install for both jobs. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2160 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-id: 20240215155009.2422335-1-peter.maydell@linaro.org (cherry picked from commit 8e31b744fdf2c5d933681e4128acee72a83af4b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 16 February 2024, 15:51:32 UTC |
| d5bc76f | Kevin Wolf | 09 February 2024, 17:31:03 UTC | iotests: Make 144 deterministic again Since commit effd60c8 changed how QMP commands are processed, the order of the block-commit return value and job events in iotests 144 wasn't fixed and more and caused the test to fail intermittently. Change the test to cache events first and then print them in a predefined order. Waiting three times for JOB_STATUS_CHANGE is a bit uglier than just waiting for the JOB_STATUS_CHANGE that has "status": "ready", but the tooling we have doesn't seem to allow the latter easily. Fixes: effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2126 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20240209173103.239994-1-kwolf@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit cc29c12ec629ba68a4a6cb7d165c94cc8502815a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 16 February 2024, 11:28:18 UTC |
| f030e96 | Peter Maydell | 08 February 2024, 15:33:46 UTC | target/arm: Don't get MDCR_EL2 in pmu_counter_enabled() before checking ARM_FEATURE_PMU It doesn't make sense to read the value of MDCR_EL2 on a non-A-profile CPU, and in fact if you try to do it we will assert: #6 0x00007ffff4b95e96 in __GI___assert_fail (assertion=0x5555565a8c70 "!arm_feature(env, ARM_FEATURE_M)", file=0x5555565a6e5c "../../target/arm/helper.c", line=12600, function=0x5555565a9560 <__PRETTY_FUNCTION__.0> "arm_security_space_below_el3") at ./assert/assert.c:101 #7 0x0000555555ebf412 in arm_security_space_below_el3 (env=0x555557bc8190) at ../../target/arm/helper.c:12600 #8 0x0000555555ea6f89 in arm_is_el2_enabled (env=0x555557bc8190) at ../../target/arm/cpu.h:2595 #9 0x0000555555ea942f in arm_mdcr_el2_eff (env=0x555557bc8190) at ../../target/arm/internals.h:1512 We might call pmu_counter_enabled() on an M-profile CPU (for example from the migration pre/post hooks in machine.c); this should always return false because these CPUs don't set ARM_FEATURE_PMU. Avoid the assertion by not calling arm_mdcr_el2_eff() before we have done the early return for "PMU not present". This fixes an assertion failure if you try to do a loadvm or savevm for an M-profile board. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2155 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240208153346.970021-1-peter.maydell@linaro.org (cherry picked from commit ac1d88e9e7ca0bed83e91e07ce6d0597f10cc77d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 16 February 2024, 11:26:24 UTC |
| 429c11c | Richard Henderson | 15 February 2024, 11:30:45 UTC | target/arm: Fix SVE/SME gross MTE suppression checks The TBI and TCMA bits are located within mtedesc, not desc. Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Gustavo Romero <gustavo.romero@linaro.org> Message-id: 20240207025210.8837-7-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 855f94eca80c85a99f459e36684ea2f98f6a3243) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> | 16 February 2024, 11:19:15 UTC |
