sort by:
Revision Author Date Message Commit Date
77e0322 target/sh4: Fix mac.l with saturation enabled The saturation arithmetic logic in helper_macl is not correct. I tested and verified this behavior on a SH7091. Signed-off-by: Zack Buhman <zack@buhman.org> Message-Id: <20240404162641.27528-2-zack@buhman.org> [rth: Reformat helper_macl, add a test case.] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit c97e8977dcacb3fa8362ee28bcee75ceb01fceaa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 17:32:12 UTC
7fc1bcb target/sh4: Merge mach and macl into a union Allow host access to the entire 64-bit accumulator. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 7d95db5e78a24d3315e3112d26909a7262355cb7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 17:32:12 UTC
be88ed8 target/sh4: mac.w: memory accesses are 16-bit words Before this change, executing a code sequence such as: mova tblm,r0 mov r0,r1 mova tbln,r0 clrs clrmac mac.w @r0+,@r1+ mac.w @r0+,@r1+ .align 4 tblm: .word 0x1234 .word 0x5678 tbln: .word 0x9abc .word 0xdefg Does not result in correct behavior: Expected behavior: first macw : macl = 0x1234 * 0x9abc + 0x0 mach = 0x0 second macw: macl = 0x5678 * 0xdefg + 0xb00a630 mach = 0x0 Observed behavior (qemu-sh4eb, prior to this commit): first macw : macl = 0x5678 * 0xdefg + 0x0 mach = 0x0 second macw: (unaligned longword memory access, SIGBUS) Various SH-4 ISA manuals also confirm that `mac.w` is a 16-bit word memory access, not a 32-bit longword memory access. Signed-off-by: Zack Buhman <zack@buhman.org> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20240402093756.27466-1-zack@buhman.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit b0f2f2976b4db05351117b0440b32bf0aac2c5c6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 17:32:12 UTC
c02844b linux-user: Fix waitid return of siginfo_t and rusage The copy back to siginfo_t should be conditional only on arg3, not the specific values that might have been written. The copy back to rusage was missing entirely. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2262 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Fan <alex.fan.q@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit f0907ff4cae743f1a4ef3d0a55a047029eed06ff) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 15:54:46 UTC
196601e tcg/optimize: Do not attempt to constant fold neg_vec Split out the tail of fold_neg to fold_neg_no_const so that we can avoid attempting to constant fold vector negate. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2150 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e25fe886b89a396bae5847520b70c148587d490a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 10 April 2024, 15:51:37 UTC
20cd0c8 virtio-snd: rewrite invalid tx/rx message handling The current handling of invalid virtqueue elements inside the TX/RX virt queue handlers is wrong. They are added in a per-stream invalid queue to be processed after the handler is done examining each message, but the invalid message might not be specifying any stream_id; which means it's invalid to add it to any stream->invalid queue since stream could be NULL at this point. This commit moves the invalid queue to the VirtIOSound struct which guarantees there will always be a valid temporary place to store them inside the tx/rx handlers. The queue will be emptied before the handler returns, so the queue must be empty at any other point of the device's lifetime. Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <virtio-snd-rewrite-invalid-tx-rx-message-handling-v1.manos.pitsidianakis@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 731655f87f319fd06f27282c6cafbc2467ac8045) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 18:15:05 UTC
627aa46 virtio-snd: Enhance error handling for invalid transfers This patch improves error handling in virtio_snd_handle_tx_xfer() and virtio_snd_handle_rx_xfer() in the VirtIO sound driver. Previously, 'goto' statements were used for error paths, leading to unnecessary processing and potential null pointer dereferences. Now, 'continue' is used to skip the rest of the current loop iteration for errors such as message size discrepancies or null streams, reducing crash risks. ASAN log illustrating the issue addressed: ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4 #0 0x57cea39967b8 in qemu_mutex_lock_impl qemu/util/qemu-thread-posix.c:92:5 #1 0x57cea128c462 in qemu_mutex_lock qemu/include/qemu/thread.h:122:5 #2 0x57cea128d72f in qemu_lockable_lock qemu/include/qemu/lockable.h:95:5 #3 0x57cea128c294 in qemu_lockable_auto_lock qemu/include/qemu/lockable.h:105:5 #4 0x57cea1285eb2 in virtio_snd_handle_rx_xfer qemu/hw/audio/virtio-snd.c:1026:9 #5 0x57cea2caebbc in virtio_queue_notify_vq qemu/hw/virtio/virtio.c:2268:9 #6 0x57cea2cae412 in virtio_queue_host_notifier_read qemu/hw/virtio/virtio.c:3671:9 #7 0x57cea39822f1 in aio_dispatch_handler qemu/util/aio-posix.c:372:9 #8 0x57cea3979385 in aio_dispatch_handlers qemu/util/aio-posix.c:414:20 #9 0x57cea3978eb1 in aio_dispatch qemu/util/aio-posix.c:424:5 #10 0x57cea3a1eede in aio_ctx_dispatch qemu/util/async.c:360:5 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Message-Id: <20240322110827.568412-1-zheyuma97@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a45f09935c88ae352a5ec120418a8b2b36ec1daa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 18:15:00 UTC
cd461c8 vdpa-dev: Fix the issue of device status not updating when configuration interruption is triggered The set_config callback function vhost_vdpa_device_get_config in vdpa-dev does not fetch the current device status from the hardware device, causing the guest os to not receive the latest device status information. The hardware updates the config status of the vdpa device and then notifies the os. The guest os receives an interrupt notification, triggering a get_config access in the kernel, which then enters qemu internally. Ultimately, the vhost_vdpa_device_get_config function of vdpa-dev is called One scenario encountered is when the device needs to bring down the vdpa net device. After modifying the status field of virtio_net_config in the hardware, it sends an interrupt notification. However, the guest os always receives the STATUS field as VIRTIO_NET_S_LINK_UP. Signed-off-by: Yuxue Liu <yuxue.liu@jaguarmicro.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20240408020003.1979-1-yuxue.liu@jaguarmicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 6ae72f609a21cfc56bf655cd4bcded5d07691ce7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:42:59 UTC
b57b102 hw/virtio: Fix packed virtqueue flush used_idx In the event of writing many chains of descriptors, the device must write just the id of the last buffer in the descriptor chain, skip forward the number of descriptors in the chain, and then repeat the operations for the rest of chains. Current QEMU code writes all the buffer ids consecutively, and then skips all the buffers altogether. This is a bug, and can be reproduced with a VirtIONet device with _F_MRG_RXBUB and without _F_INDIRECT_DESC: If a virtio-net device has the VIRTIO_NET_F_MRG_RXBUF feature but not the VIRTIO_RING_F_INDIRECT_DESC feature, 'VirtIONetQueue->rx_vq' will use the merge feature to store data in multiple 'elems'. The 'num_buffers' in the virtio header indicates how many elements are merged. If the value of 'num_buffers' is greater than 1, all the merged elements will be filled into the descriptor ring. The 'idx' of the elements should be the value of 'vq->used_idx' plus 'ndescs'. Fixes: 86044b24e8 ("virtio: basic packed virtqueue support") Acked-by: Eugenio Pérez <eperezma@redhat.com> Signed-off-by: Wafer <wafer@jaguarmicro.com> Message-Id: <20240407015451.5228-2-wafer@jaguarmicro.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2d9a31b3c27311eca1682cb2c076d7a300441960) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:39:47 UTC
f7a1ff6 target/arm: Use correct SecuritySpace for AArch64 AT ops at EL3 When we do an AT address translation operation, the page table walk is supposed to be performed in the context of the EL we're doing the walk for, so for instance an AT S1E2R walk is done for EL2. In the pseudocode an EL is passed to AArch64.AT(), which calls SecurityStateAtEL() to find the security state that we should be doing the walk with. In ats_write64() we get this wrong, instead using the current security space always. This is fine for AT operations performed from EL1 and EL2, because there the current security state and the security state for the lower EL are the same. But for AT operations performed from EL3, the current security state is always either Secure or Root, whereas we want to use the security state defined by SCR_EL3.{NS,NSE} for the walk. This affects not just guests using FEAT_RME but also ones where EL3 is Secure state and the EL3 code is trying to do an AT for a NonSecure EL2 or EL1. Use arm_security_space_below_el3() to get the SecuritySpace to pass to do_ats_write() for all AT operations except the AT S1E3* operations. Cc: qemu-stable@nongnu.org Fixes: e1ee56ec2383 ("target/arm: Pass security space rather than flag for AT instructions") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2250 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240405180232.3570066-1-peter.maydell@linaro.org (cherry picked from commit 19b254e86a900dc5ee332e3ac0baf9c521301abf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:19:43 UTC
6983d16 migration/postcopy: ensure preempt channel is ready before loading states Before loading the guest states, ensure that the preempt channel has been ready to use, as some of the states (e.g. via virtio_load) might trigger page faults that will be handled through the preempt channel. So yield to the main thread in the case that the channel create event hasn't been dispatched. Cc: qemu-stable <qemu-stable@nongnu.org> Fixes: 9358982744 ("migration: Send requested page directly in rp-return thread") Originally-by: Lei Wang <lei4.wang@intel.com> Link: https://lore.kernel.org/all/9aa5d1be-7801-40dd-83fd-f7e041ced249@intel.com/T/ Signed-off-by: Lei Wang <lei4.wang@intel.com> Signed-off-by: Wei Wang <wei.w.wang@intel.com> Link: https://lore.kernel.org/r/20240405034056.23933-1-wei.w.wang@intel.com [peterx: add a todo section, add Fixes and copy stable for 8.0+] Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 7afbdada7effbc2b97281bfbce0c6df351a3cf88) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:18:26 UTC
46f03be block/virtio-blk: Fix memory leak from virtio_blk_zone_report This modification ensures that in scenarios where the buffer size is insufficient for a zone report, the function will now properly set an error status and proceed to a cleanup label, instead of merely returning. The following ASAN log reveals it: ==1767400==ERROR: LeakSanitizer: detected memory leaks Direct leak of 312 byte(s) in 1 object(s) allocated from: #0 0x64ac7b3280cd in malloc llvm/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 #1 0x735b02fb9738 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5e738) #2 0x64ac7d23be96 in virtqueue_split_pop hw/virtio/virtio.c:1612:12 #3 0x64ac7d23728a in virtqueue_pop hw/virtio/virtio.c:1783:16 #4 0x64ac7cfcaacd in virtio_blk_get_request hw/block/virtio-blk.c:228:27 #5 0x64ac7cfca7c7 in virtio_blk_handle_vq hw/block/virtio-blk.c:1123:23 #6 0x64ac7cfecb95 in virtio_blk_handle_output hw/block/virtio-blk.c:1157:5 Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Message-id: 20240404120040.1951466-1-zheyuma97@gmail.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit bbdf9023665f409113cb07b463732861af63fb47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 April 2024, 17:13:20 UTC
9c2b819 hw/net/virtio-net: fix qemu set used ring flag even vhost started When vhost-user or vhost-kernel is handling virtio net datapath, QEMU should not touch used ring. But with vhost-user socket reconnect scenario, in a very rare case (has pending kick event). VRING_USED_F_NO_NOTIFY is set by QEMU in following code path: #0 virtio_queue_split_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:511 #1 0x0000559d6dbf033b in virtio_queue_set_notification (vq=0x7ff5f4c920a8, enable=0) at ../hw/virtio/virtio.c:576 #2 0x0000559d6dbbbdbc in virtio_net_handle_tx_bh (vdev=0x559d703a6aa0, vq=0x7ff5f4c920a8) at ../hw/net/virtio-net.c:2801 #3 0x0000559d6dbf4791 in virtio_queue_notify_vq (vq=0x7ff5f4c920a8) at ../hw/virtio/virtio.c:2248 #4 0x0000559d6dbf79da in virtio_queue_host_notifier_read (n=0x7ff5f4c9211c) at ../hw/virtio/virtio.c:3525 #5 0x0000559d6d9a5814 in virtio_bus_cleanup_host_notifier (bus=0x559d703a6a20, n=1) at ../hw/virtio/virtio-bus.c:321 #6 0x0000559d6dbf83c9 in virtio_device_stop_ioeventfd_impl (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3774 #7 0x0000559d6d9a55c8 in virtio_bus_stop_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:259 #8 0x0000559d6d9a53e8 in virtio_bus_grab_ioeventfd (bus=0x559d703a6a20) at ../hw/virtio/virtio-bus.c:199 #9 0x0000559d6dbf841c in virtio_device_grab_ioeventfd (vdev=0x559d703a6aa0) at ../hw/virtio/virtio.c:3783 #10 0x0000559d6d9bde18 in vhost_dev_enable_notifiers (hdev=0x559d707edd70, vdev=0x559d703a6aa0) at ../hw/virtio/vhost.c:1592 #11 0x0000559d6d89a0b8 in vhost_net_start_one (net=0x559d707edd70, dev=0x559d703a6aa0) at ../hw/net/vhost_net.c:266 #12 0x0000559d6d89a6df in vhost_net_start (dev=0x559d703a6aa0, ncs=0x559d7048d890, data_queue_pairs=31, cvq=0) at ../hw/net/vhost_net.c:412 #13 0x0000559d6dbb5b89 in virtio_net_vhost_status (n=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:311 #14 0x0000559d6dbb5e34 in virtio_net_set_status (vdev=0x559d703a6aa0, status=15 '\017') at ../hw/net/virtio-net.c:392 #15 0x0000559d6dbb60d8 in virtio_net_set_link_status (nc=0x559d7048d890) at ../hw/net/virtio-net.c:455 #16 0x0000559d6da64863 in qmp_set_link (name=0x559d6f0b83d0 "hostnet1", up=true, errp=0x7ffdd76569f0) at ../net/net.c:1459 #17 0x0000559d6da7226e in net_vhost_user_event (opaque=0x559d6f0b83d0, event=CHR_EVENT_OPENED) at ../net/vhost-user.c:301 #18 0x0000559d6ddc7f63 in chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:62 #19 0x0000559d6ddc7fdc in qemu_chr_be_event (s=0x559d6f2ffea0, event=CHR_EVENT_OPENED) at ../chardev/char.c:82 This issue causes guest kernel stop kicking device and traffic stop. Add vhost_started check in virtio_net_handle_tx_bh to fix this wrong VRING_USED_F_NO_NOTIFY set. Signed-off-by: Yajun Wu <yajunw@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20240402045109.97729-1-yajunw@nvidia.com> [PMD: Use unlikely()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 4c54f5bc8e1d38f15cc35b6a6932d8fbe219c692) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 03 April 2024, 05:10:35 UTC
e961fa4 target/arm: take HSTR traps of cp15 accesses to EL2, not EL1 The HSTR_EL2 register allows the hypervisor to trap AArch32 EL1 and EL0 accesses to cp15 registers. We incorrectly implemented this so they trap to EL1 when we detect the need for a HSTR trap at code generation time. (The check in access_check_cp_reg() which we do at runtime to catch traps from EL0 is correctly routing them to EL2.) Use the correct target EL when generating the code to take the trap. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2226 Fixes: 049edada5e93df ("target/arm: Make HSTR_EL2 traps take priority over UNDEF-at-EL1") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240325133116.2075362-1-peter.maydell@linaro.org (cherry picked from commit fbe5ac5671a9cfcc7f4aee9a5fac7720eea08876) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 02 April 2024, 16:48:17 UTC
2702763 hw/intc/arm_gicv3: ICC_HPPIR* return SPURIOUS if int group is disabled If the group of the highest priority pending interrupt is disabled via ICC_IGRPEN*, the ICC_HPPIR* registers should return INTID_SPURIOUS, not the interrupt ID. (See the GIC architecture specification pseudocode functions ICC_HPPIR1_EL1[] and HighestPriorityPendingInterrupt().) Make HPPIR reads honour the group disable, the way we already do when determining whether to preempt in icc_hppi_can_preempt(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240328153333.2522667-1-peter.maydell@linaro.org (cherry picked from commit 44e25fbc1900c99c91a44e532c5bd680bc403459) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 02 April 2024, 16:45:01 UTC
2befb8a gitlab-ci/cirrus: switch from 'master' to 'latest' Commit ab72522797 "gitlab: switch from 'stable' to 'latest' docker container tags" switched most tags to 'latest' but missed cirrus image. Fix this now. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2256 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Message-id: 20240401051633.2780456-1-mjt@tls.msk.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1d2f2b35bc86b7a13dc3009a3c5031220aa0b7de) 01 April 2024, 16:30:40 UTC
3168476 migration/postcopy: Ensure postcopy_start() sets errp if it fails There are several places where postcopy_start() fails without setting errp. This can cause a null pointer de-reference, as in case of error, the caller of postcopy_start() copies/prints the error set in errp. Fix it by setting errp in all of postcopy_start() error paths. Cc: qemu-stable <qemu-stable@nongnu.org> Fixes: 908927db28ea ("migration: Update error description whenever migration fails") Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240328140252.16756-3-avihaih@nvidia.com Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit d0ad271a7613459bd0a3397c8071a4ad06f3f7eb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 April 2024, 16:30:21 UTC
35fface target/hppa: Clear psw_n for BE on use_nullify_skip path Along this path we have already skipped the insn to be nullified, so the subsequent insn should be executed. Cc: qemu-stable@nongnu.org Reported-by: Sven Schnelle <svens@stackframe.org> Tested-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4a3aa11e1fb25c28c24a43fd2835c429b00a463d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 01 April 2024, 16:23:57 UTC
3cdfd68 tcg/optimize: Fix sign_mask for logical right-shift The 'sign' computation is attempting to locate the sign bit that has been repeated, so that we can test if that bit is known zero. That computation can be zero if there are no known sign repetitions. Cc: qemu-stable@nongnu.org Fixes: 93a967fbb57 ("tcg/optimize: Propagate sign info for shifting") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2248 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 2911e9b95f3bb03783ae5ca3e2494dc3b44a9161) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 31 March 2024, 19:14:59 UTC
d3e9e0f hw/net/net_tx_pkt: Fix virtio header without checksum offloading It is incorrect to have the VIRTIO_NET_HDR_F_NEEDS_CSUM set when checksum offloading is disabled so clear the bit. TCP/UDP checksum is usually offloaded when the peer requires virtio headers because they can instruct the peer to compute checksum. However, igb disables TX checksum offloading when a VF is enabled whether the peer requires virtio headers because a transmitted packet can be routed to it and it expects the packet has a proper checksum. Therefore, it is necessary to have a correct virtio header even when checksum offloading is disabled. A real TCP/UDP checksum will be computed and saved in the buffer when checksum offloading is disabled. The virtio specification requires to set the packet checksum stored in the buffer to the TCP/UDP pseudo header when the VIRTIO_NET_HDR_F_NEEDS_CSUM bit is set so the bit must be cleared in that case. Fixes: ffbd2dbd8e64 ("e1000e: Perform software segmentation for loopback") Buglink: https://issues.redhat.com/browse/RHEL-23067 Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 89a8de364b51db8107d2a210314431885ac52238) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 31 March 2024, 19:13:04 UTC
12e4886 virtio-net: Fix vhost virtqueue notifiers for RSS virtio_net_guest_notifier_pending() and virtio_net_guest_notifier_mask() checked VIRTIO_NET_F_MQ to know there are multiple queues, but VIRTIO_NET_F_RSS also enables multiple queues. Refer to n->multiqueue, which is set to true either of VIRTIO_NET_F_MQ or VIRTIO_NET_F_RSS is enabled. Fixes: 68b0a6395f36 ("virtio-net: align ctrl_vq index for non-mq guest for vhost_vdpa") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 1c188fc8cbffc5f05cc616cab4e1372fb6e6f11f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 31 March 2024, 19:11:27 UTC
1e4ec09 target/riscv/kvm: fix timebase-frequency when using KVM acceleration The timebase-frequency of guest OS should be the same with host machine. The timebase-frequency value in DTS should be got from hypervisor when using KVM acceleration. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Message-ID: <20240314061510.9800-1-yongxuan.wang@sifive.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix due to missing other changes in this area in 8.2.x) 27 March 2024, 10:04:06 UTC
38f36fc target/riscv: Fix mode in riscv_tlb_fill Need to convert mmu_idx to privilege mode for PMP function. Signed-off-by: Irina Ryapolova <irina.ryapolova@syntacore.com> Fixes: b297129ae1 ("target/riscv: propagate PMP permission to TLB page") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240320172828.23965-1-irina.ryapolova@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit e06adebb08325c39e4c9b652139426c10f021abb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:25 UTC
dc2abb6 target/riscv: rvv: Remove the dependency of Zvfbfmin to Zfbfmin According to the Zvfbfmin definition in the RISC-V BF16 extensions spec, the Zvfbfmin extension only requires either the V extension or the Zve32f extension. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240321170929.1162507-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c9b07fe14d3525cd3f2fc01f46eeb3d4ed7c3603) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:25 UTC
6c49cca hw/intc: Update APLIC IDC after claiming iforce register Currently, QEMU only sets the iforce register to 0 and returns early when claiming the iforce register. However, this may leave mip.meip remains at 1 if a spurious external interrupt triggered by iforce register is the only pending interrupt to be claimed, and the interrupt cannot be lowered as expected. This commit fixes this issue by calling riscv_aplic_idc_update() to update the IDC status after the iforce register is claimed. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240321104951.12104-1-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 078189b327ae5c5727b51ec714d9663b1d0ca3df) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:25 UTC
b7ff2c5 target/riscv/vector_helper.c: optimize loops in ldst helpers Change the for loops in ldst helpers to do a single increment in the counter, and assign it env->vstart, to avoid re-reading from vstart every time. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 0a11629c915f61df798919db51a18ffe4649cb65) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:25 UTC
c4ed8c5 target/riscv/vector_helpers: do early exit when vstart >= vl We're going to make changes that will required each helper to be responsible for the 'vstart' management, i.e. we will relieve the 'vstart < vl' assumption that helpers have today. Helpers are usually able to deal with vstart >= vl, i.e. doing nothing aside from setting vstart = 0 at the end, but the tail update functions will update the tail regardless of vstart being valid or not. Unifying the tail update process in a single function that would handle the vstart >= vl case isn't trivial (see [1] for more info). This patch takes a blunt approach: do an early exit in every single vector helper if vstart >= vl, unless the helper is guarded with vstart_eq_zero in the translation. For those cases the helper is ready to deal with cases where vl might be zero, i.e. throwing exceptions based on it like vcpop_m() and first_m(). Helpers that weren't changed: - vcpop_m(), vfirst_m(), vmsetm(), GEN_VEXT_VIOTA_M(): these are guarded directly with vstart_eq_zero; - GEN_VEXT_VCOMPRESS_VM(): guarded with vcompress_vm_check() that checks vstart_eq_zero; - GEN_VEXT_RED(): guarded with either reduction_check() or reduction_widen_check(), both check vstart_eq_zero; - GEN_VEXT_FRED(): guarded with either freduction_check() or freduction_widen_check(), both check vstart_eq_zero. Another exception is vext_ldst_whole(), who operates on effective vector length regardless of the current settings in vtype and vl. [1] https://lore.kernel.org/qemu-riscv/1590234b-0291-432a-a0fa-c5a6876097bc@linux.alibaba.com/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240314175704.478276-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit df4252b2ecaf93b601109373a17427d1867046e8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:21 UTC
43ca6c1 target/riscv: always clear vstart in whole vec move insns These insns have 2 paths: we'll either have vstart already cleared if vstart_eq_zero or we'll do a brcond to check if vstart >= maxsz to call the 'vmvr_v' helper. The helper will clear vstart if it executes until the end, or if vstart >= vl. For starters, the check itself is wrong: we're checking vstart >= maxsz, when in fact we should use vstart in bytes, or 'startb' like 'vmvr_v' is calling, to do the comparison. But even after fixing the comparison we'll still need to clear vstart in the end, which isn't happening too. We want to make the helpers responsible to manage vstart, including these corner cases, precisely to avoid these situations: - remove the wrong vstart >= maxsz cond from the translation; - add a 'startb >= maxsz' cond in 'vmvr_v', and clear vstart if that happens. This way we're now sure that vstart is being cleared in the end of the execution, regardless of the path taken. Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7e53e3ddf6dff200098e112c5370ab16d2d5dbd1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:14 UTC
693ceca target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianess vmvr_v isn't handling the case where the host might be big endian and the bytes to be copied aren't sequential. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 768e7b329c0be22035da077fe76221dd0a47103b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:14 UTC
9f0db88 trans_rvv.c.inc: set vstart = 0 in int scalar move insns trans_vmv_x_s, trans_vmv_s_x, trans_vfmv_f_s and trans_vfmv_s_f aren't setting vstart = 0 after execution. This is usually done by a helper in vector_helper.c but these functions don't use helpers. We'll set vstart after any potential 'over' brconds, and that will also mandate a mark_vs_dirty() too. Fixes: dedc53cbc9 ("target/riscv: rvv-1.0: integer scalar move instructions") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240314175704.478276-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 0848f7c18ef50de9f955e7eeb4363d92766a41bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:14 UTC
bf26b6a target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX() The helper isn't setting env->vstart = 0 after its execution, as it is expected from every vector instruction that completes successfully. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240314175704.478276-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit d3646e31ce6d1e02e46e6eabdbc2e637c0cbece7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 March 2024, 10:00:14 UTC
0041b5a 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Update version for 8.2.2 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 04 March 2024, 12:15:46 UTC
2121469 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 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 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 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 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 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 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
back to top