aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-05-22nbd/server: Fix drained_poll to wake coroutine in right AioContextKevin Wolf
nbd_drained_poll() generally runs in the main thread, not whatever iothread the NBD server coroutine is meant to run in, so it can't directly reenter the coroutines to wake them up. The code seems to have the right intention, it specifies the correct AioContext when it calls qemu_aio_coroutine_enter(). However, this functions doesn't schedule the coroutine to run in that AioContext, but it assumes it is already called in the home thread of the AioContext. To fix this, add a new thread-safe qio_channel_wake_read() that can be called in the main thread to wake up the coroutine in its AioContext, and use this in nbd_drained_poll(). Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230517152834.277483-3-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 7c1f51bf38de8cea4ed5030467646c37b46edeb7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22graph-lock: Disable locking for nowKevin Wolf
In QEMU 8.0, we've been seeing deadlocks in bdrv_graph_wrlock(). They come from callers that hold an AioContext lock, which is not allowed during polling. In theory, we could temporarily release the lock, but callers are inconsistent about whether they hold a lock, and if they do, some are also confused about which one they hold. While all of this is fixable, it's not trivial, and the best course of action for 8.0.1 is probably just disabling the graph locking code temporarily. We don't currently rely on graph locking yet. It is supposed to replace the AioContext lock eventually to enable multiqueue support, but as long as we still have the AioContext lock, it is sufficient without the graph lock. Once the AioContext lock goes away, the deadlock doesn't exist any more either and this commit can be reverted. (Of course, it can also be reverted while the AioContext lock still exists if the callers have been fixed.) Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230517152834.277483-2-kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 80fc5d260002432628710f8b0c7cfc7d9b97bb9d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22block: compile out assert_bdrv_graph_readable() by defaultStefan Hajnoczi
reader_count() is a performance bottleneck because the global aio_context_list_lock mutex causes thread contention. Put this debugging assertion behind a new ./configure --enable-debug-graph-lock option and disable it by default. The --enable-debug-graph-lock option is also enabled by the more general --enable-debug option. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230501173443.153062-1-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 58a2e3f5c37be02dac3086b81bdda9414b931edf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: pick this one up so the next patch which disables this applies cleanly)
2023-05-22tested: add test for nested aio_poll() in poll handlersStefan Hajnoczi
Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230502184134.534703-3-stefanha@redhat.com> [kwolf: Restrict to CONFIG_POSIX, Windows doesn't support polling] Tested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 844a12a63e12b1235a8fc17f9b278929dc6eb00e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22aio-posix: do not nest poll handlersStefan Hajnoczi
QEMU's event loop supports nesting, which means that event handler functions may themselves call aio_poll(). The condition that triggered a handler must be reset before the nested aio_poll() call, otherwise the same handler will be called and immediately re-enter aio_poll. This leads to an infinite loop and stack exhaustion. Poll handlers are especially prone to this issue, because they typically reset their condition by finishing the processing of pending work. Unfortunately it is during the processing of pending work that nested aio_poll() calls typically occur and the condition has not yet been reset. Disable a poll handler during ->io_poll_ready() so that a nested aio_poll() call cannot invoke ->io_poll_ready() again. As a result, the disabled poll handler and its associated fd handler do not run during the nested aio_poll(). Calling aio_set_fd_handler() from inside nested aio_poll() could cause it to run again. If the fd handler is pending inside nested aio_poll(), then it will also run again. In theory fd handlers can be affected by the same issue, but they are more likely to reset the condition before calling nested aio_poll(). This is a special case and it's somewhat complex, but I don't see a way around it as long as nested aio_poll() is supported. Cc: qemu-stable@nongnu.org Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2186181 Fixes: c38270692593 ("block: Mark bdrv_co_io_(un)plug() and callers GRAPH_RDLOCK") Cc: Kevin Wolf <kwolf@redhat.com> Cc: Emanuele Giuseppe Esposito <eesposit@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230502184134.534703-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 6d740fb01b9f0f5ea7a82f4d5e458d91940a19ee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22virtio-crypto: fix NULL pointer dereference in virtio_crypto_free_requestMauro Matteo Cascella
Ensure op_info is not NULL in case of QCRYPTODEV_BACKEND_ALG_SYM algtype. Fixes: 0e660a6f90a ("crypto: Introduce RSA algorithm") Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com> Reported-by: Yiming Tao <taoym@zju.edu.cn> Message-Id: <20230509075317.1132301-1-mcascell@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: zhenwei pi<pizhenwei@bytedance.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 3e69908907f8d3dd20d5753b0777a6e3824ba824) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22virtio-net: not enable vq reset feature unconditionallyEugenio Pérez
The commit 93a97dc5200a ("virtio-net: enable vq reset feature") enables unconditionally vq reset feature as long as the device is emulated. This makes impossible to actually disable the feature, and it causes migration problems from qemu version previous than 7.2. The entire final commit is unneeded as device system already enable or disable the feature properly. This reverts commit 93a97dc5200a95e63b99cb625f20b7ae802ba413. Fixes: 93a97dc5200a ("virtio-net: enable vq reset feature") Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230504101447.389398-1-eperezma@redhat.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 1fac00f70b3261050af5564b20ca55c1b2a3059a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-22hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0Leonardo Bras
Since it's implementation on v8.0.0-rc0, having the PCI_ERR_UNCOR_MASK set for machine types < 8.0 will cause migration to fail if the target QEMU version is < 8.0.0 : qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40 device: 0 cmask: ff wmask: 0 w1cmask:0 qemu-system-x86_64: Failed to load PCIDevice:config qemu-system-x86_64: Failed to load e1000e:parent_obj qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:02.0/e1000e' qemu-system-x86_64: load of migration failed: Invalid argument The above test migrated a 7.2 machine type from QEMU master to QEMU 7.2.0, with this cmdline: ./qemu-system-x86_64 -M pc-q35-7.2 [-incoming XXX] In order to fix this, property x-pcie-err-unc-mask was introduced to control when PCI_ERR_UNCOR_MASK is enabled. This property is enabled by default, but is disabled if machine type <= 7.2. Fixes: 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register") Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Leonardo Bras <leobras@redhat.com> Message-Id: <20230503002701.854329-1-leobras@redhat.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1576 Tested-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 5ed3dabe57dd9f4c007404345e5f5bf0e347317f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-19vhost: fix possible wrap in SVQ descriptor ringHawkins Jiawei
QEMU invokes vhost_svq_add() when adding a guest's element into SVQ. In vhost_svq_add(), it uses vhost_svq_available_slots() to check whether QEMU can add the element into SVQ. If there is enough space, then QEMU combines some out descriptors and some in descriptors into one descriptor chain, and adds it into `svq->vring.desc` by vhost_svq_vring_write_descs(). Yet the problem is that, `svq->shadow_avail_idx - svq->shadow_used_idx` in vhost_svq_available_slots() returns the number of occupied elements, or the number of descriptor chains, instead of the number of occupied descriptors, which may cause wrapping in SVQ descriptor ring. Here is an example. In vhost_handle_guest_kick(), QEMU forwards as many available buffers to device by virtqueue_pop() and vhost_svq_add_element(). virtqueue_pop() returns a guest's element, and then this element is added into SVQ by vhost_svq_add_element(), a wrapper to vhost_svq_add(). If QEMU invokes virtqueue_pop() and vhost_svq_add_element() `svq->vring.num` times, vhost_svq_available_slots() thinks QEMU just ran out of slots and everything should work fine. But in fact, virtqueue_pop() returns `svq->vring.num` elements or descriptor chains, more than `svq->vring.num` descriptors due to guest memory fragmentation, and this causes wrapping in SVQ descriptor ring. This bug is valid even before marking the descriptors used. If the guest memory is fragmented, SVQ must add chains so it can try to add more descriptors than possible. This patch solves it by adding `num_free` field in VhostShadowVirtqueue structure and updating this field in vhost_svq_add() and vhost_svq_get_buf(), to record the number of free descriptors. Fixes: 100890f7ca ("vhost: Shadow virtqueue buffers forwarding") Signed-off-by: Hawkins Jiawei <yin31149@gmail.com> Acked-by: Eugenio Pérez <eperezma@redhat.com> Message-Id: <20230509084817.3973-1-yin31149@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> (cherry picked from commit 5d410557dea452f6231a7c66155e29a37e168528) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18target/i386: fix avx2 instructions vzeroall and vpermdqXinyu Li
vzeroall: xmm_regs should be used instead of xmm_t0 vpermdq: bit 3 and 7 of imm should be considered Signed-off-by: Xinyu Li <lixinyu20s@ict.ac.cn> Message-Id: <20230510145222.586487-1-lixinyu20s@ict.ac.cn> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 056d649007bc9fdae9f1d576e77c1316e9a34468) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18target/i386: fix operand size for VCOMI/VUCOMI instructionsPaolo Bonzini
Compared to other SSE instructions, VUCOMISx and VCOMISx are different: the single and double precision versions are distinguished through a prefix, however they use no-prefix and 0x66 for SS and SD respectively. Scalar values usually are associated with 0xF2 and 0xF3. Because of these, they incorrectly perform a 128-bit memory load instead of a 32- or 64-bit load. Fix this by writing a custom decoding function. I tested that the reproducer is fixed and the test-avx output does not change. Reported-by: Gabriele Svelto <gsvelto@mozilla.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1637 Fixes: f8d19eec0d53 ("target/i386: reimplement 0x0f 0x28-0x2f, add AVX", 2022-10-18) Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2b55e479e6fcbb466585fd25077a50c32e10dc3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18scsi-generic: fix buffer overflow on block limits inquiryPaolo Bonzini
Using linux 6.x guest, at boot time, an inquiry on a scsi-generic device makes qemu crash. This is caused by a buffer overflow when scsi-generic patches the block limits VPD page. Do the operations on a temporary on-stack buffer that is guaranteed to be large enough. Reported-by: Théo Maillart <tmaillart@freebox.fr> Analyzed-by: Théo Maillart <tmaillart@freebox.fr> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9bd634b2f5e2f10fe35d7609eb83f30583f2e15a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18target/arm: Fix vd == vm overlap in sve_ldff1_zRichard Henderson
If vd == vm, copy vm to scratch, so that we can pre-zero the output and still access the gather indicies. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1612 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230504104232.1877774-1-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit a6771f2f5cbfbf312e2fb5b1627f38a6bf6321d0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18migration: Attempt disk reactivation in more failure scenariosEric Blake
Commit fe904ea824 added a fail_inactivate label, which tries to reactivate disks on the source after a failure while s->state == MIGRATION_STATUS_ACTIVE, but didn't actually use the label if qemu_savevm_state_complete_precopy() failed. This failure to reactivate is also present in commit 6039dd5b1c (also covering the new s->state == MIGRATION_STATUS_DEVICE state) and 403d18ae (ensuring s->block_inactive is set more reliably). Consolidate the two labels back into one - no matter HOW migration is failed, if there is any chance we can reach vm_start() after having attempted inactivation, it is essential that we have tried to restart disks before then. This also makes the cleanup more like migrate_fd_cancel(). Suggested-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20230502205212.134680-1-eblake@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 6dab4c93ecfae48e2e67b984d1032c1e988d3005) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: minor context tweak near added comment in migration/migration.c)
2023-05-18migration: Minor control flow simplificationEric Blake
No need to declare a temporary variable. Suggested-by: Juan Quintela <quintela@redhat.com> Fixes: 1df36e8c6289 ("migration: Handle block device inactivation failures better") Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit 5d39f44d7ac5c63f53d4d0900ceba9521bc27e49) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18migration: Handle block device inactivation failures betterEric Blake
Consider what happens when performing a migration between two host machines connected to an NFS server serving multiple block devices to the guest, when the NFS server becomes unavailable. The migration attempts to inactivate all block devices on the source (a necessary step before the destination can take over); but if the NFS server is non-responsive, the attempt to inactivate can itself fail. When that happens, the destination fails to get the migrated guest (good, because the source wasn't able to flush everything properly): (qemu) qemu-kvm: load of migration failed: Input/output error at which point, our only hope for the guest is for the source to take back control. With the current code base, the host outputs a message, but then appears to resume: (qemu) qemu-kvm: qemu_savevm_state_complete_precopy_non_iterable: bdrv_inactivate_all() failed (-1) (src qemu)info status VM status: running but a second migration attempt now asserts: (src qemu) qemu-kvm: ../block.c:6738: int bdrv_inactivate_recurse(BlockDriverState *): Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. Whether the guest is recoverable on the source after the first failure is debatable, but what we do not want is to have qemu itself fail due to an assertion. It looks like the problem is as follows: In migration.c:migration_completion(), the source sets 'inactivate' to true (since COLO is not enabled), then tries savevm.c:qemu_savevm_state_complete_precopy() with a request to inactivate block devices. In turn, this calls block.c:bdrv_inactivate_all(), which fails when flushing runs up against the non-responsive NFS server. With savevm failing, we are now left in a state where some, but not all, of the block devices have been inactivated; but migration_completion() then jumps to 'fail' rather than 'fail_invalidate' and skips an attempt to reclaim those those disks by calling bdrv_activate_all(). Even if we do attempt to reclaim disks, we aren't taking note of failure there, either. Thus, we have reached a state where the migration engine has forgotten all state about whether a block device is inactive, because we did not set s->block_inactive in enough places; so migration allows the source to reach vm_start() and resume execution, violating the block layer invariant that the guest CPUs should not be restarted while a device is inactive. Note that the code in migration.c:migrate_fd_cancel() will also try to reactivate all block devices if s->block_inactive was set, but because we failed to set that flag after the first failure, the source assumes it has reclaimed all devices, even though it still has remaining inactivated devices and does not try again. Normally, qmp_cont() will also try to reactivate all disks (or correctly fail if the disks are not reclaimable because NFS is not yet back up), but the auto-resumption of the source after a migration failure does not go through qmp_cont(). And because we have left the block layer in an inconsistent state with devices still inactivated, the later migration attempt is hitting the assertion failure. Since it is important to not resume the source with inactive disks, this patch marks s->block_inactive before attempting inactivation, rather than after succeeding, in order to prevent any vm_start() until it has successfully reactivated all devices. See also https://bugzilla.redhat.com/show_bug.cgi?id=2058982 Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Acked-by: Lukas Straub <lukasstraub2@web.de> Tested-by: Lukas Straub <lukasstraub2@web.de> Signed-off-by: Juan Quintela <quintela@redhat.com> (cherry picked from commit 403d18ae384239876764bbfa111d6cc5dcb673d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18linux-user: fix getgroups/setgroups allocationsMichael Tokarev
linux-user getgroups(), setgroups(), getgroups32() and setgroups32() used alloca() to allocate grouplist arrays, with unchecked gidsetsize coming from the "guest". With NGROUPS_MAX being 65536 (linux, and it is common for an application to allocate NGROUPS_MAX for getgroups()), this means a typical allocation is half the megabyte on the stack. Which just overflows stack, which leads to immediate SIGSEGV in actual system getgroups() implementation. An example of such issue is aptitude, eg https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087#72 Cap gidsetsize to NGROUPS_MAX (return EINVAL if it is larger than that), and use heap allocation for grouplist instead of alloca(). While at it, fix coding style and make all 4 implementations identical. Try to not impose random limits - for example, allow gidsetsize to be negative for getgroups() - just do not allocate negative-sized grouplist in this case but still do actual getgroups() call. But do not allow negative gidsetsize for setgroups() since its argument is unsigned. Capping by NGROUPS_MAX seems a bit arbitrary, - we can do more, it is not an error if set size will be NGROUPS_MAX+1. But we should not allow integer overflow for the array being allocated. Maybe it is enough to just call g_try_new() and return ENOMEM if it fails. Maybe there's also no need to convert setgroups() since this one is usually smaller and known beforehand (KERN_NGROUPS_MAX is actually 63, - this is apparently a kernel-imposed limit for runtime group set). The patch fixes aptitude segfault mentioned above. Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <20230409105327.1273372-1-mjt@msgid.tls.msk.ru> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 1e35d327890bdd117a67f79c52e637fb12bb1bf4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18linux-user: Fix mips fp64 executables loadingDaniil Kovalev
If a program requires fr1, we should set the FR bit of CP0 control status register and add F64 hardware flag. The corresponding `else if` branch statement is copied from the linux kernel sources (see `arch_check_elf` function in linux/arch/mips/kernel/elf.c). Signed-off-by: Daniil Kovalev <dkovalev@compiler-toolchain-for.me> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Message-Id: <20230404052153.16617-1-dkovalev@compiler-toolchain-for.me> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit a0f8d2701b205d9d7986aa555e0566b13dc18fa0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-18tests/docker: bump the xtensa base to debian:11-slimAlex Bennée
Stretch is going out of support so things like security updates will fail. As the toolchain itself is binary it hopefully won't mind the underlying OS being updated. Message-Id: <20230503091244.1450613-3-alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reported-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3217b84f3cd813a7daffc64b26543c313f3a042a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-17docs/about/emulation: fix typoLizhi Yang
Duplicated word "are". Signed-off-by: Lizhi Yang <sledgeh4w@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230511080119.99018-1-sledgeh4w@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit c70bb9a771d467302d1c7df5c5bd56b48f42716e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-17util/async-teardown: wire up query-command-line-optionsClaudio Imbrenda
Add new -run-with option with an async-teardown=on|off parameter. It is visible in the output of query-command-line-options QMP command, so it can be discovered and used by libvirt. The option -async-teardown is now redundant, deprecate it. Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Fixes: c891c24b1a ("os-posix: asynchronous teardown for shutdown on Linux") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20230505120051.36605-2-imbrenda@linux.ibm.com> [thuth: Add curly braces to fix error with GCC 8.5, fix bug in deprecated.rst] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 80bd81cadd127c1e2fc784612a52abe392670ba4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context tweak in docs/about/deprecated.rst)
2023-05-17s390x/pv: Fix spurious warning with asynchronous teardownClaudio Imbrenda
Kernel commit 292a7d6fca33 ("KVM: s390: pv: fix asynchronous teardown for small VMs") causes the KVM_PV_ASYNC_CLEANUP_PREPARE ioctl to fail if the VM is not larger than 2GiB. QEMU would attempt it and fail, print an error message, and then proceed with a normal teardown. Avoid attempting to use asynchronous teardown altogether when the VM is not larger than 2 GiB. This will avoid triggering the error message and also avoid pointless overhead; normal teardown is fast enough for small VMs. Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Fixes: c3a073c610 ("s390x/pv: Add support for asynchronous teardown for reboot") Link: https://lore.kernel.org/all/20230421085036.52511-2-imbrenda@linux.ibm.com/ Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-Id: <20230510105531.30623-2-imbrenda@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Fix inline function parameter in pv.h] Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 88693ab2a53f2f3d25cb39a7b5034ab391bc5a81) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-17tcg/i386: Set P_REXW in tcg_out_addi_ptrRichard Henderson
The REXW bit must be set to produce a 64-bit pointer result; the bit is disabled in 32-bit mode, so we can do this unconditionally. Fixes: 7d9e1ee424b0 ("tcg/i386: Adjust assert in tcg_out_addi_ptr") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1592 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1642 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 988998503bc6d8c03fbea001a0513e8372fddf28) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-179pfs/xen: Fix segfault on shutdownJason Andryuk
xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed out when free is called. Do the teardown in _disconnect(). This matches the setup done in _connect(). trace-events are also added for the XenDevOps functions. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Message-Id: <20230502143722.15613-1-jandryuk@gmail.com> [C.S.: - Remove redundant return in xen_9pfs_free(). - Add comment to trace-events. ] Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> (cherry picked from commit 92e667f6fd5806a6a705a2a43e572bd9ec6819da) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-17s390x/tcg: Fix LDER instruction formatIlya Leoshkevich
It's RRE, not RXE. Found by running valgrind's none/tests/s390x/bfp-2. Fixes: 86b59624c4aa ("s390x/tcg: Implement LOAD LENGTHENED short HFP to long HFP") Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230511134726.469651-1-iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 970641de01908dd09b569965e78f13842e5854bc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-16target/s390x: Fix EXECUTE of relative branchesIlya Leoshkevich
Fix a problem similar to the one fixed by commit 703d03a4aaf3 ("target/s390x: Fix EXECUTE of relative long instructions"), but now for relative branches. Reported-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230426235813.198183-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit e8ecdfeb30f087574191cde523e846e023911c8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-15tcg: ppc64: Fix mask generation for vextractdmShivaprasad G Bhat
In function do_extractm() the mask is calculated as dup_const(1 << (element_width - 1)). '1' being signed int works fine for MO_8,16,32. For MO_64, on PPC64 host this ends up becoming 0 on compilation. The vextractdm uses MO_64, and it ends up having mask as 0. Explicitly use 1ULL instead of signed int 1 like its used everywhere else. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1536 Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Lucas Mateus Castro <lucas.araujo@eldorado.org.br> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <168319292809.1159309.5817546227121323288.stgit@ltc-boston1.aus.stglabs.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 6a5d81b17201ab8a95539bad94c8a6c08a42e076) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-15async: Suppress GCC13 false positive in aio_bh_poll()Cédric Le Goater
GCC13 reports an error : ../util/async.c: In function ‘aio_bh_poll’: include/qemu/queue.h:303:22: error: storing the address of local variable ‘slice’ in ‘*ctx.bh_slice_list.sqh_last’ [-Werror=dangling-pointer=] 303 | (head)->sqh_last = &(elm)->field.sqe_next; \ | ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ ../util/async.c:169:5: note: in expansion of macro ‘QSIMPLEQ_INSERT_TAIL’ 169 | QSIMPLEQ_INSERT_TAIL(&ctx->bh_slice_list, &slice, next); | ^~~~~~~~~~~~~~~~~~~~ ../util/async.c:161:17: note: ‘slice’ declared here 161 | BHListSlice slice; | ^~~~~ ../util/async.c:161:17: note: ‘ctx’ declared here But the local variable 'slice' is removed from the global context list in following loop of the same routine. Add a pragma to silent GCC. Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20230420202939.1982044-1-clg@kaod.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit d66ba6dc1cce914673bd8a89fca30a7715ea70d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: cherry-picked to stable-8.0 to eliminate CI failures on win*)
2023-05-14target/arm: Correct AArch64.S2MinTxSZ 32-bit EL1 input size checkPeter Maydell
In check_s2_mmu_setup() we have a check that is attempting to implement the part of AArch64.S2MinTxSZ that is specific to when EL1 is AArch32: if !s1aarch64 then // EL1 is AArch32 min_txsz = Min(min_txsz, 24); Unfortunately we got this wrong in two ways: (1) The minimum txsz corresponds to a maximum inputsize, but we got the sense of the comparison wrong and were faulting for all inputsizes less than 40 bits (2) We try to implement this as an extra check that happens after we've done the same txsz checks we would do for an AArch64 EL1, but in fact the pseudocode is *loosening* the requirements, so that txsz values that would fault for an AArch64 EL1 do not fault for AArch32 EL1, because it does Min(old_min, 24), not Max(old_min, 24). You can see this also in the text of the Arm ARM in table D8-8, which shows that where the implemented PA size is less than 40 bits an AArch32 EL1 is still OK with a configured stage2 T0SZ for a 40 bit IPA, whereas if EL1 is AArch64 then the T0SZ must be big enough to constrain the IPA to the implemented PA size. Because of part (2), we can't do this as a separate check, but have to integrate it into aa64_va_parameters(). Add a new argument to that function to indicate that EL1 is 32-bit. All the existing callsites except the one in get_phys_addr_lpae() can pass 'false', because they are either doing a lookup for a stage 1 regime or else they don't care about the tsz/tsz_oob fields. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1627 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230509092059.3176487-1-peter.maydell@linaro.org (cherry picked from commit 478dccbb99db0bf8f00537dd0b4d0de88d5cb537) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-14ui: Fix pixel colour channel order for PNG screenshotsPeter Maydell
When we take a PNG screenshot the ordering of the colour channels in the data is not correct, resulting in the image having weird colouring compared to the actual display. (Specifically, on a little-endian host the blue and red channels are swapped; on big-endian everything is wrong.) This happens because the pixman idea of the pixel data and the libpng idea differ. PIXMAN_a8r8g8b8 defines that pixels are 32-bit values, with A in bits 24-31, R in bits 16-23, G in bits 8-15 and B in bits 0-7. This means that on little-endian systems the bytes in memory are B G R A and on big-endian systems they are A R G B libpng, on the other hand, thinks of pixels as being a series of values for each channel, so its format PNG_COLOR_TYPE_RGB_ALPHA always wants bytes in the order R G B A This isn't the same as the pixman order for either big or little endian hosts. The alpha channel is also unnecessary bulk in the output PNG file, because there is no alpha information in a screenshot. To handle the endianness issue, we already define in ui/qemu-pixman.h various PIXMAN_BE_* and PIXMAN_LE_* values that give consistent byte-order pixel channel formats. So we can use PIXMAN_BE_r8g8b8 and PNG_COLOR_TYPE_RGB, which both have an in-memory byte order of R G B and 3 bytes per pixel. (PPM format screenshots get this right; they already use the PIXMAN_BE_r8g8b8 format.) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1622 Fixes: 9a0a119a382867 ("Added parameter to take screenshot with screendump as PNG") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20230502135548.2451309-1-peter.maydell@linaro.org (cherry picked from commit cd22a0f520f471e3bd33bc19cf3b2fa772cdb2a8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-14target/arm: Fix handling of SW and NSW bits for stage 2 walksPeter Maydell
We currently don't correctly handle the VSTCR_EL2.SW and VTCR_EL2.NSW configuration bits. These allow configuration of whether the stage 2 page table walks for Secure IPA and NonSecure IPA should do their descriptor reads from Secure or NonSecure physical addresses. (This is separate from how the translation table base address and other parameters are set: an NS IPA always uses VTTBR_EL2 and VTCR_EL2 for its base address and walk parameters, regardless of the NSW bit, and similarly for Secure.) Provide a new function ptw_idx_for_stage_2() which returns the MMU index to use for descriptor reads, and use it to set up the .in_ptw_idx wherever we call get_phys_addr_lpae(). For a stage 2 walk, wherever we call get_phys_addr_lpae(): * .in_ptw_idx should be ptw_idx_for_stage_2() of the .in_mmu_idx * .in_secure should be true if .in_mmu_idx is Stage2_S This allows us to correct S1_ptw_translate() so that it consistently always sets its (out_secure, out_phys) to the result it gets from the S2 walk (either by calling get_phys_addr_lpae() or by TLB lookup). This makes better conceptual sense because the S2 walk should return us an (address space, address) tuple, not an address that we then randomly assign to S or NS. Our previous handling of SW and NSW was broken, so guest code trying to use these bits to put the s2 page tables in the "other" address space wouldn't work correctly. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1600 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230504135425.2748672-3-peter.maydell@linaro.org (cherry picked from commit fcc0b0418fff655f20fd0cf86a1bbdc41fd2e7c6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-11accel/tcg: Fix atomic_mmu_lookup for readsRichard Henderson
A copy-paste bug had us looking at the victim cache for writes. Cc: qemu-stable@nongnu.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Fixes: 08dff435e2 ("tcg: Probe the proper permissions for atomic ops") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20230505204049.352469-1-richard.henderson@linaro.org> (cherry picked from commit 8c313254e61ed47a1bf4a2db714b25cdd94fbcce) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/pci-bridge: pci_expander_bridge fix type in pxb_cxl_dev_reset()Jonathan Cameron
Reproduce issue with configure --enable-qom-cast-debug ... qemu-system-x86_64 -display none -machine q35,cxl=on -device pxb-cxl,bus=pcie.0 hw/pci-bridge/pci_expander_bridge.c:54:PXB_DEV: Object 0x5570e0b1ada0 is not an instance of type pxb Aborted The type conversion results in the right state structure, but PXB_DEV is not a parent of PXB_CXL_DEV hence the error. Rather than directly cleaning up the inheritance, this is the minimal fix which will be followed by the cleanup. Fixes: 154070eaf6 ("hw/pxb-cxl: Support passthrough HDM Decoders unless overridden") Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Message-Id: <20230420142750.6950-2-Jonathan.Cameron@huawei.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9136f661c7277777a2f85a7e98438f4fe6472fdc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10target/riscv: Restore the predicate() NULL check behaviorBin Meng
When reading a non-existent CSR QEMU should raise illegal instruction exception, but currently it just exits due to the g_assert() check. This actually reverts commit 0ee342256af9205e7388efdf193a6d8f1ba1a617. Some comments are also added to indicate that predicate() must be provided for an implemented CSR. Reported-by: Fei Wu <fei2.wu@intel.com> Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-Id: <20230417043054.3125614-1-bmeng@tinylab.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit eae04c4c131a8d95087c8568eb2cac1988262f25) (mjt: context edit after ce3af0bbbcdfa "target/riscv: add support for Zcmt extension") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10target/riscv: Fix itrigger when icount is usedLIU Zhiwei
When I boot a ubuntu image, QEMU output a "Bad icount read" message and exit. The reason is that when execute helper_mret or helper_sret, it will cause a call to icount_get_raw_locked (), which needs set can_do_io flag on cpustate. Thus we setting this flag when execute these two instructions. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230324064011.976-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit df3ac6da476e346a17bad5bc843de1135a269229) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10block: Don't call no_coroutine_fns in qmp_block_resize()Kevin Wolf
This QMP handler runs in a coroutine, so it must use the corresponding no_co_wrappers instead. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2185688 Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230504115750.54437-5-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 0c7d204f50c382c6baac8c94bd57af4a022b3888) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10block: bdrv/blk_co_unref() for calls in coroutine contextKevin Wolf
These functions must not be called in coroutine context, because they need write access to the graph. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230504115750.54437-4-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit b2ab5f545fa1eaaf2955dd617bee19a8b3279786) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10block: Consistently call bdrv_activate() outside coroutineKevin Wolf
Migration code can call bdrv_activate() in coroutine context, whereas other callers call it outside of coroutines. As it calls other code that is not supposed to run in coroutines, standardise on running outside of coroutines. This adds a no_co_wrapper to switch to the main loop before calling bdrv_activate(). Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20230504115750.54437-3-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit da4afaff074e56b0fa0d25abf865784148018895) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10block: Fix use after free in blockdev_mark_auto_del()Kevin Wolf
job_cancel_locked() drops the job list lock temporarily and it may call aio_poll(). We must assume that the list has changed after this call. Also, with unlucky timing, it can end up freeing the job during job_completed_txn_abort_locked(), making the job pointer invalid, too. For both reasons, we can't just continue at block_job_next_locked(job). Instead, start at the head of the list again after job_cancel_locked() and skip those jobs that we already cancelled (or that are completing anyway). Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20230503140142.474404-1-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit e2626874a32602d4e52971c786ef5ffb4430629d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10meson: leave unnecessary modules out of the buildPaolo Bonzini
meson.build files choose whether to build modules based on foo.found() expressions. If a feature is enabled (e.g. --enable-gtk), these expressions are true even if the code is not used by any emulator, and this results in an unexpected difference between modular and non-modular builds. For non-modular builds, the files are not included in any binary, and therefore the source files are never processed. For modular builds, however, all .so files are unconditionally built by default, and therefore a normal "make" tries to build them. However, the corresponding trace-*.h files are absent due to this conditional: if have_system trace_events_subdirs += [ ... 'ui', ... ] endif which was added to avoid wasting time running tracetool on unused trace-events files. This causes a compilation failure; fix it by skipping module builds entirely if (depending on the module directory) have_block or have_system are false. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ef709860ea12ec59c4cd7373bd2fd7a4e50143ee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10softfloat: Fix the incorrect computation in float32_exp2Shivaprasad G Bhat
The float32_exp2 function is computing wrong exponent of 2. For example, with the following set of values {0.1, 2.0, 2.0, -1.0}, the expected output would be {1.071773, 4.000000, 4.000000, 0.500000}. Instead, the function is computing {1.119102, 3.382044, 3.382044, -0.191022} Looking at the code, the float32_exp2() attempts to do this 2 3 4 5 n x x x x x x x e = 1 + --- + --- + --- + --- + --- + ... + --- + ... 1! 2! 3! 4! 5! n! But because of the typo it ends up doing x x x x x x x e = 1 + --- + --- + --- + --- + --- + ... + --- + ... 1! 2! 3! 4! 5! n! This is because instead of the xnp which holds the numerator, parts_muladd is using the xp which is just 'x'. Commit '572c4d862ff2' refactored this function, and mistakenly used xp instead of xnp. Cc: qemu-stable@nongnu.org Fixes: 572c4d862ff2 "softfloat: Convert float32_exp2 to FloatParts" Partially-Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1623 Reported-By: Luca Barbato (https://gitlab.com/lu-zero) Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Message-Id: <168304110865.537992.13059030916325018670.stgit@localhost.localdomain> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 1098cc3fcf952763fc9fd72c1c8fda30a18cc8ea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10block/export: call blk_set_dev_ops(blk, NULL, NULL)Stefan Hajnoczi
Most export types install BlockDeviceOps pointers. It is easy to forget to remove them because that happens automatically via the "drive" qdev property in hw/ but not block/export/. Put blk_set_dev_ops(blk, NULL, NULL) calls in the core export.c code so the export types don't need to remember. This fixes the nbd and vhost-user-blk export types. Fixes: fd6afc501a01 ("nbd/server: Use drained block ops to quiesce the server") Fixes: ca858a5fe94c ("vhost-user-blk-server: notify client about disk resize") Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20230502211119.720647-1-stefanha@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit de79b52604e43fdeba6cee4f5af600b62169f2d2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/net/allwinner-sun8i-emac: Correctly byteswap descriptor fieldsPeter Maydell
In allwinner-sun8i-emac we just read directly from guest memory into a host FrameDescriptor struct and back. This only works on little-endian hosts. Reading and writing of descriptors is already abstracted into functions; make those functions also handle the byte-swapping so that TransferDescriptor structs as seen by the rest of the code are always in host-order, and fix two places that were doing ad-hoc descriptor reading without using the functions. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230424165053.1428857-3-peter.maydell@linaro.org (cherry picked from commit a4ae17e5ec512862bf73e40dfbb1e7db71f2c1e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/sd/allwinner-sdhost: Correctly byteswap descriptor fieldsPeter Maydell
In allwinner_sdhost_process_desc() we just read directly from guest memory into a host TransferDescriptor struct and back. This only works on little-endian hosts. Abstract the reading and writing of descriptors into functions that handle the byte-swapping so that TransferDescriptor structs as seen by the rest of the code are always in host-order. This fixes a failure of one of the avocado tests on s390. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230424165053.1428857-2-peter.maydell@linaro.org (cherry picked from commit 3e20d90824c262de6887aa1bc52af94db69e4310) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10target/arm: Define and use new load_cpu_field_low32()Peter Maydell
In several places in the 32-bit Arm translate.c, we try to use load_cpu_field() to load from a CPUARMState field into a TCGv_i32 where the field is actually 64-bit. This works on little-endian hosts, but gives the wrong half of the register on big-endian. Add a new load_cpu_field_low32() which loads the low 32 bits of a 64-bit field into a TCGv_i32. The new macro includes a compile-time check against accidentally using it on a field of the wrong size. Use it to fix the two places in the code where we were using load_cpu_field() on a 64-bit field. This fixes a bug where on big-endian hosts the guest would crash after executing an ERET instruction, and a more corner case one where some UNDEFs for attempted accesses to MSR banked registers from Secure EL1 might go to the wrong EL. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230424153909.1419369-2-peter.maydell@linaro.org (cherry picked from commit 7f3a3d3dc433dc06c0adb480729af80f9c8e3739) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/intc/allwinner-a10-pic: Don't use set_bit()/clear_bit()Peter Maydell
The Allwinner PIC model uses set_bit() and clear_bit() to update the values in its irq_pending[] array when an interrupt arrives. However it is using these functions wrongly: they work on an array of type 'long', and it is passing an array of type 'uint32_t'. Because the code manually figures out the right array element, this works on little-endian hosts and on 32-bit big-endian hosts, where bits 0..31 in a 'long' are in the same place as they are in a 'uint32_t'. However it breaks on 64-bit big-endian hosts. Remove the use of set_bit() and clear_bit() in favour of using deposit32() on the array element. This fixes a bug where on big-endian 64-bit hosts the guest kernel would hang early on in bootup. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230424152833.1334136-1-peter.maydell@linaro.org (cherry picked from commit 2c5fa0778c3b4307f9f3af7f27886c46d129c62f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/arm/raspi: Use arm_write_bootloader() to write boot codePeter Maydell
When writing the secondary-CPU stub boot loader code to the guest, use arm_write_bootloader() instead of directly calling rom_add_blob_fixed(). This fixes a bug on big-endian hosts, because arm_write_bootloader() will correctly byte-swap the host-byte-order array values into the guest-byte-order to write into the guest memory. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20230424152717.1333930-4-peter.maydell@linaro.org (cherry picked from commit 0acbdb4c4ab6b0a09f159bae4899b0737cf64242) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/arm/aspeed: Use arm_write_bootloader() to write the bootloaderCédric Le Goater
When writing the secondary-CPU stub boot loader code to the guest, use arm_write_bootloader() instead of directly calling rom_add_blob_fixed(). This fixes a bug on big-endian hosts, because arm_write_bootloader() will correctly byte-swap the host-byte-order array values into the guest-byte-order to write into the guest memory. Cc: qemu-stable@nongnu.org Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20230424152717.1333930-3-peter.maydell@linaro.org [PMM: Moved the "make arm_write_bootloader() function public" part to its own patch; updated commit message to note that this fixes an actual bug; adjust to the API changes noted in previous commit] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 902bba549fc386b4b9805320ed1a2e5b68478bdd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/arm/boot: Make write_bootloader() public as arm_write_bootloader()Cédric Le Goater
The arm boot.c code includes a utility function write_bootloader() which assists in writing a boot-code fragment into guest memory, including handling endianness and fixing it up with entry point addresses and similar things. This is useful not just for the boot.c code but also in board model code, so rename it to arm_write_bootloader() and make it globally visible. Since we are making it public, make its API a little neater: move the AddressSpace* argument to be next to the hwaddr argument, and allow the fixupcontext array to be const, since we never modify it in this function. Cc: qemu-stable@nongnu.org Signed-off-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20230424152717.1333930-2-peter.maydell@linaro.org [PMM: Split out from another patch by Cédric, added doc comment] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 0fe43f0abf19bbe24df3dbf0613bb47ed55f1482) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-05-10hw/net/msf2-emac: Don't modify descriptor in-place in emac_store_desc()Peter Maydell
The msf2-emac ethernet controller has functions emac_load_desc() and emac_store_desc() which read and write the in-memory descriptor blocks and handle conversion between guest and host endianness. As currently written, emac_store_desc() does the endianness conversion in-place; this means that it effectively consumes the input EmacDesc struct, because on a big-endian host the fields will be overwritten with the little-endian versions of their values. Unfortunately, in all the callsites the code continues to access fields in the EmacDesc struct after it has called emac_store_desc() -- specifically, it looks at the d.next field. The effect of this is that on a big-endian host networking doesn't work because the address of the next descriptor is corrupted. We could fix this by making the callsite avoid using the struct; but it's more robust to have emac_store_desc() leave its input alone. (emac_load_desc() also does an in-place conversion, but here this is fine, because the function is supposed to be initializing the struct.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20230424151919.1333299-1-peter.maydell@linaro.org (cherry picked from commit d565f58b38424e9a390a7ea33ff7477bab693fda) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-23 10:27:03 +0000