aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-09-18Update version for 8.2.7 releasev8.2.7Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-17gitlab: fix logic for changing docker tag on stable branchesDaniel P. Berrangé
This fixes: commit e28112d00703abd136e2411d23931f4f891c9244 Author: Daniel P. Berrangé <berrange@redhat.com> Date: Thu Jun 8 17:40:16 2023 +0100 gitlab: stable staging branches publish containers in a separate tag Due to a copy+paste mistake, that commit included "QEMU_JOB_SKIPPED" in the final rule that was meant to be a 'catch all' for staging branches. As a result stable branches are still splattering dockers from the primary development branch. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Message-ID: <20240906140958.84755-1-berrange@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8d5ab746b1e6668ffb0378820b25665b385c8573) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-16ui/sdl2: set swap interval explicitly when OpenGL is enabledGert Wollny
Before 176e3783f2ab (ui/sdl2: OpenGL window context) SDL_CreateRenderer was called unconditionally setting the swap interval to 0. Since SDL_CreateRenderer is now no longer called when OpenGL is enabled, the swap interval is no longer set explicitly and vsync handling depends on the environment settings which may lead to a performance regression with virgl as reported in https://gitlab.com/qemu-project/qemu/-/issues/2565 Restore the old vsync handling by explicitly calling SDL_GL_SetSwapInterval if OpenGL is enabled. Fixes: 176e3783f2ab (ui/sdl2: OpenGL window context) Closes: https://gitlab.com/qemu-project/qemu/-/issues/2565 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <01020191e05ce6df-84da6386-62c2-4ce8-840e-ad216ac253dd-000000@eu-west-1.amazonses.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit ae23cd00170baaa2777eb1ee87b70f472dbb3c44) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-14hw/intc/arm_gic: fix spurious level triggered interruptsJan Klötzke
On GICv2 and later, level triggered interrupts are pending when either the interrupt line is asserted or the interrupt was made pending by a GICD_ISPENDRn write. Making a level triggered interrupt pending by software persists until either the interrupt is acknowledged or cleared by writing GICD_ICPENDRn. As long as the interrupt line is asserted, the interrupt is pending in any case. This logic is transparently implemented in gic_test_pending() for GICv1 and GICv2. The function combines the "pending" irq_state flag (used for edge triggered interrupts and software requests) and the line status (tracked in the "level" field). However, we also incorrectly set the pending flag on a guest write to GICD_ISENABLERn if the line of a level triggered interrupt was asserted. This keeps the interrupt pending even if the line is de-asserted after some time. This incorrect logic is a leftover of the initial 11MPCore GIC implementation. That handles things slightly differently to the architected GICv1 and GICv2. The 11MPCore TRM does not give a lot of detail on the corner cases of its GIC's behaviour, and historically we have not wanted to investigate exactly what it does in reality, so QEMU's GIC model takes the approach of "retain our existing behaviour for 11MPCore, and implement the architectural standard for later GIC revisions". On that basis, commit 8d999995e45c10 in 2013 is where we added the "level-triggered interrupt with the line asserted" handling to gic_test_pending(), and we deliberately kept the old behaviour of gic_test_pending() for REV_11MPCORE. That commit should have added the "only if 11MPCore" condition to the setting of the pending bit on writes to GICD_ISENABLERn, but forgot it. Add the missing "if REV_11MPCORE" condition, so that our behaviour on GICv1 and GICv2 matches the GIC architecture requirements. Cc: qemu-stable@nongnu.org Fixes: 8d999995e45c10 ("arm_gic: Fix GIC pending behavior") Signed-off-by: Jan Klötzke <jan.kloetzke@kernkonzept.com> Message-id: 20240911114826.3558302-1-jan.kloetzke@kernkonzept.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: expanded comment a little and converted to coding-style form; expanded commit message with the historical backstory] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 110684c9a69a02cbabfbddcd3afa921826ad565c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-14hw/audio/virtio-sound: fix heap buffer overflowVolker Rümelin
Currently, the guest may write to the device configuration space, whereas the virtio sound device specification in chapter 5.14.4 clearly states that the fields in the device configuration space are driver-read-only. Remove the set_config function from the virtio_snd class. This also prevents a heap buffer overflow. See QEMU issue #2296. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2296 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20240901130112.8242-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 7fc6611cad3e9627b23ce83e550b668abba6c886) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-12tests/docker: update debian i686 and mipsel images to bookwormAlex Bennée
Whatever issues there were which stopped these being updates when the rest were have now been resolved. However mips64el continues to be broken so don't update it here. Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240910173900.4154726-3-alex.bennee@linaro.org> (cherry picked from commit 19d2111059c87d3f58349f27b9be9dee81fc1681) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-12tests/docker: remove debian-armel-crossAlex Bennée
As debian-11 transitions to LTS we are starting to have problems building the image. While we could update to a later Debian building a 32 bit QEMU without modern floating point is niche host amongst the few remaining 32 bit hosts we regularly build for. For now we still have armhf-debian-cross-container which is currently built from the more recent debian-12. Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240910173900.4154726-2-alex.bennee@linaro.org> (cherry picked from commit d0068b746a0a8cd4bb148527a0d199b130cd5288) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: force-remove tests/docker/dockerfiles/debian-armel-cross.docker)
2024-09-12hw/display/vhost-user-gpu.c: fix vhost_user_gpu_chr_read()Haoran Zhang
fix vhost_user_gpu_chr_read() where `size` was incorrectly passed to `msg->flags`. Fixes: 267f664658 ("hw/display: add vhost-user-vga & gpu-pci") Signed-off-by: Haoran Zhang <wh1sper@zju.edu.cn> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit d6192f3f7593536a4285e8ab6c6cf3f34973ce62) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-12crypto: check gnutls & gcrypt support the requested pbkdf hashDaniel P. Berrangé
Both gnutls and gcrypt can be configured to exclude support for certain algorithms via a runtime check against system crypto policies. Thus it is not sufficient to have a compile time test for hash support in their pbkdf implementations. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit e6c09ea4f9e5f8af92a6453642b84b9efd52892f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-12crypto: run qcrypto_pbkdf2_count_iters in a new threadTiago Pasqualini
CPU time accounting in the kernel has been demonstrated to have a sawtooth pattern[1][2]. This can cause the getrusage system call to not be as accurate as we are expecting, which can cause this calculation to stall. The kernel discussions shows that this inaccuracy happens when CPU time gets big enough, so this patch changes qcrypto_pbkdf2_count_iters to run in a fresh thread to avoid this inaccuracy. It also adds a sanity check to fail the process if CPU time is not accounted. [1] https://lore.kernel.org/lkml/159231011694.16989.16351419333851309713.tip-bot2@tip-bot2/ [2] https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing.lan@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534 Resolves: #2398 Signed-off-by: Tiago Pasqualini <tiago.pasqualini@canonical.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit c72cab5ad9f849bbcfcf4be7952b8b8946cc626e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-12softmmu/physmem: fix memory leak in dirty_memory_extend()David Hildenbrand
As reported by Peter, we might be leaking memory when removing the highest RAMBlock (in the weird ram_addr_t space), and adding a new one. We will fail to realize that we already allocated bitmaps for more dirty memory blocks, and effectively discard the pointers to them. Fix it by getting rid of last_ram_page() and by remembering the number of dirty memory blocks that have been allocated already. While at it, let's use "unsigned int" for the number of blocks, which should be sufficient until we reach ~32 exabytes. Looks like this leak was introduced as we switched from using a single bitmap_zero_extend() to allocating multiple bitmaps: bitmap_zero_extend() relies on g_renew() which should have taken care of this. Resolves: https://lkml.kernel.org/r/CAFEAcA-k7a+VObGAfCFNygQNfCKL=AfX6A4kScq=VSSK0peqPg@mail.gmail.com Reported-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 5b82b703b69a ("memory: RCU ram_list.dirty_memory[] for safe RAM hotplug") Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-stable@nongnu.org Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20240828090743.128647-1-david@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit b84f06c2bee727b3870b4eeccbe3a45c5aea14c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix due to lack of v9.0.0-rc4-49-g15f7a80c49cb "RAMBlock: Add support of KVM private guest memfd")
2024-09-06target/ppc: Fix migration of CPUs with TLB_EMB TLB typeArman Nabiev
In vmstate_tlbemb a cut-and-paste error meant we gave this vmstate subsection the same "cpu/tlb6xx" name as the vmstate_tlb6xx subsection. This breaks migration load for any CPU using the TLB_EMB CPU type, because when we see the "tlb6xx" name in the incoming data we try to interpret it as a vmstate_tlb6xx subsection, which it isn't the right format for: $ qemu-system-ppc -drive if=none,format=qcow2,file=/home/petmay01/test-images/virt/dummy.qcow2 -monitor stdio -M bamboo QEMU 9.0.92 monitor - type 'help' for more information (qemu) savevm foo (qemu) loadvm foo Missing section footer for cpu Error: Error -22 while loading VM state Correct the incorrect vmstate section name. Since migration for these CPU types was completely broken before, we don't need to care that this is a migration compatibility break. This affects the PPC 405, 440, 460 and e200 CPU families. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2522 Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Arman Nabiev <nabiev.arman13@gmail.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> (cherry picked from commit 203beb6f047467a4abfc8267c234393cea3f471c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-06gitlab: migrate the s390x custom machine to 22.04Alex Bennée
20.04 is dead (from QEMU's point of view), long live 22.04! Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240426153938.1707723-3-alex.bennee@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 108d99742af1fa6e977dcfac9d4151b7915e33a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-09-05target/hppa: Fix PSW V-bit packaging in cpu_hppa_get for hppa64Helge Deller
While adding hppa64 support, the psw_v variable got extended from 32 to 64 bits. So, when packaging the PSW-V bit from the psw_v variable for interrupt processing, check bit 31 instead the 63th (sign) bit. This fixes a hard to find Linux kernel boot issue where the loss of the PSW-V bit due to an ITLB interruption in the middle of a series of ds/addc instructions (from the divU milicode library) generated the wrong division result and thus triggered a Linux kernel crash. Link: https://lore.kernel.org/lkml/718b8afe-222f-4b3a-96d3-93af0e4ceff1@roeck-us.net/ Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Fixes: 931adff31478 ("target/hppa: Update cpu_hppa_get/put_psw for hppa64") Cc: qemu-stable@nongnu.org # v8.2+ (cherry picked from commit ead5078cf1a5f11d16e3e8462154c859620bcc7e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in target/hppa/helper.c due to lack of v9.0.0-688-gebc9401a4067 "target/hppa: Split PSW X and B into their own field")
2024-08-30hw/audio/virtio-snd: fix invalid param checkVolker Rümelin
Commit 9b6083465f ("virtio-snd: check for invalid param shift operands") tries to prevent invalid parameters specified by the guest. However, the code is not correct. Change the code so that the parameters format and rate, which are a bit numbers, are compared with the bit size of the data type. Fixes: 9b6083465f ("virtio-snd: check for invalid param shift operands") Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20240802071805.7123-1-vr_qemu@t-online.de> Reviewed-by: Manos Pitsidianakis <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 7d14471a121878602cb4e748c4707f9ab9a9e3e2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28virtio-pci: Fix the use of an uninitialized irqfdCindy Lu
The crash was reported in MAC OS and NixOS, here is the link for this bug https://gitlab.com/qemu-project/qemu/-/issues/2334 https://gitlab.com/qemu-project/qemu/-/issues/2321 In this bug, they are using the virtio_input device. The guest notifier was not supported for this device, The function virtio_pci_set_guest_notifiers() was not called, and the vector_irqfd was not initialized. So the fix is adding the check for vector_irqfd in virtio_pci_get_notifier() The function virtio_pci_get_notifier() can be used in various devices. It could also be called when VIRTIO_CONFIG_S_DRIVER_OK is not set. In this situation, the vector_irqfd being NULL is acceptable. We can allow the device continue to boot If the vector_irqfd still hasn't been initialized after VIRTIO_CONFIG_S_DRIVER_OK is set, it means that the function set_guest_notifiers was not called before the driver started. This indicates that the device is not using the notifier. At this point, we will let the check fail. This fix is verified in vyatta,MacOS,NixOS,fedora system. The bt tree for this bug is: Thread 6 "CPU 0/KVM" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7c817be006c0 (LWP 1269146)] kvm_virtio_pci_vq_vector_use () at ../qemu-9.0.0/hw/virtio/virtio-pci.c:817 817 if (irqfd->users == 0) { (gdb) thread apply all bt ... Thread 6 (Thread 0x7c817be006c0 (LWP 1269146) "CPU 0/KVM"): 0 kvm_virtio_pci_vq_vector_use () at ../qemu-9.0.0/hw/virtio/virtio-pci.c:817 1 kvm_virtio_pci_vector_use_one () at ../qemu-9.0.0/hw/virtio/virtio-pci.c:893 2 0x00005983657045e2 in memory_region_write_accessor () at ../qemu-9.0.0/system/memory.c:497 3 0x0000598365704ba6 in access_with_adjusted_size () at ../qemu-9.0.0/system/memory.c:573 4 0x0000598365705059 in memory_region_dispatch_write () at ../qemu-9.0.0/system/memory.c:1528 5 0x00005983659b8e1f in flatview_write_continue_step.isra.0 () at ../qemu-9.0.0/system/physmem.c:2713 6 0x000059836570ba7d in flatview_write_continue () at ../qemu-9.0.0/system/physmem.c:2743 7 flatview_write () at ../qemu-9.0.0/system/physmem.c:2774 8 0x000059836570bb76 in address_space_write () at ../qemu-9.0.0/system/physmem.c:2894 9 0x0000598365763afe in address_space_rw () at ../qemu-9.0.0/system/physmem.c:2904 10 kvm_cpu_exec () at ../qemu-9.0.0/accel/kvm/kvm-all.c:2917 11 0x000059836576656e in kvm_vcpu_thread_fn () at ../qemu-9.0.0/accel/kvm/kvm-accel-ops.c:50 12 0x0000598365926ca8 in qemu_thread_start () at ../qemu-9.0.0/util/qemu-thread-posix.c:541 13 0x00007c8185bcd1cf in ??? () at /usr/lib/libc.so.6 14 0x00007c8185c4e504 in clone () at /usr/lib/libc.so.6 Fixes: 2ce6cff94d ("virtio-pci: fix use of a released vector") Cc: qemu-stable@nongnu.org Signed-off-by: Cindy Lu <lulu@redhat.com> Message-Id: <20240806093715.65105-1-lulu@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit a8e63ff289d137197ad7a701a587cc432872d798) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/nvme: fix leak of uninitialized memory in io_mgmt_recvKlaus Jensen
Yutaro Shimizu from the Cyber Defense Institute discovered a bug in the NVMe emulation that leaks contents of an uninitialized heap buffer if subsystem and FDP emulation are enabled. Cc: qemu-stable@nongnu.org Reported-by: Yutaro Shimizu <shimizu@cyberdefense.jp> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit 6a22121c4f25b181e99479f65958ecde65da1c92) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28crypto/tlscredspsk: Free username on finalizePeter Maydell
When the creds->username property is set we allocate memory for it in qcrypto_tls_creds_psk_prop_set_username(), but we never free this when the QCryptoTLSCredsPSK is destroyed. Free the memory in finalize. This fixes a LeakSanitizer complaint in migration-test: $ (cd build/asan; ASAN_OPTIONS="fast_unwind_on_malloc=0" QTEST_QEMU_BINARY=./qemu-system-x86_64 ./tests/qtest/migration-test --tap -k -p /x86_64/migration/precopy/unix/tls/psk) ================================================================= ==3867512==ERROR: LeakSanitizer: detected memory leaks Direct leak of 5 byte(s) in 1 object(s) allocated from: #0 0x5624e5c99dee in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-x86_64+0x218edee) (BuildId: a9e623fa1009a9435c0142c037cd7b8c1ad04ce3) #1 0x7fb199ae9738 in g_malloc debian/build/deb/../../../glib/gmem.c:128:13 #2 0x7fb199afe583 in g_strdup debian/build/deb/../../../glib/gstrfuncs.c:361:17 #3 0x5624e82ea919 in qcrypto_tls_creds_psk_prop_set_username /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../crypto/tlscredspsk.c:255:23 #4 0x5624e812c6b5 in property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/object.c:2277:5 #5 0x5624e8125ce5 in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/object.c:1463:5 #6 0x5624e8136e7c in object_set_properties_from_qdict /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/object_interfaces.c:55:14 #7 0x5624e81372d2 in user_creatable_add_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/object_interfaces.c:112:5 #8 0x5624e8137964 in user_creatable_add_qapi /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/object_interfaces.c:157:11 #9 0x5624e891ba3c in qmp_object_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qom/qom-qmp-cmds.c:227:5 #10 0x5624e8af9118 in qmp_marshal_object_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qapi/qapi-commands-qom.c:337:5 #11 0x5624e8bd1d49 in do_qmp_dispatch_bh /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../qapi/qmp-dispatch.c:128:5 #12 0x5624e8cb2531 in aio_bh_call /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/async.c:171:5 #13 0x5624e8cb340c in aio_bh_poll /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/async.c:218:13 #14 0x5624e8c0be98 in aio_dispatch /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/aio-posix.c:423:5 #15 0x5624e8cba3ce in aio_ctx_dispatch /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/async.c:360:5 #16 0x7fb199ae0d3a in g_main_dispatch debian/build/deb/../../../glib/gmain.c:3419:28 #17 0x7fb199ae0d3a in g_main_context_dispatch debian/build/deb/../../../glib/gmain.c:4137:7 #18 0x5624e8cbe1d9 in glib_pollfds_poll /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/main-loop.c:287:9 #19 0x5624e8cbcb13 in os_host_main_loop_wait /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/main-loop.c:310:5 #20 0x5624e8cbc6dc in main_loop_wait /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../util/main-loop.c:589:11 #21 0x5624e6f3f917 in qemu_main_loop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../system/runstate.c:801:9 #22 0x5624e893379c in qemu_default_main /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../system/main.c:37:14 #23 0x5624e89337e7 in main /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/../../system/main.c:48:12 #24 0x7fb197972d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #25 0x7fb197972e3f in __libc_start_main csu/../csu/libc-start.c:392:3 #26 0x5624e5c16fa4 in _start (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/qemu-system-x86_64+0x210bfa4) (BuildId: a9e623fa1009a9435c0142c037cd7b8c1ad04ce3) SUMMARY: AddressSanitizer: 5 byte(s) leaked in 1 allocation(s). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-ID: <20240819145021.38524-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 87e012f29f2e47dcd8c385ff8bb8188f9e06d4ea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/sparc: Restrict STQF to sparcv9Richard Henderson
Prior to sparcv9, the same encoding was STDFQ. Cc: qemu-stable@nongnu.org Fixes: 06c060d9e5b ("target/sparc: Move simple fp load/store to decodetree") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240816072311.353234-2-richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 12d36294a2d978faf893101862118d1ac1815e85) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/hexagon: don't look for static glibAlyssa Ross
When cross compiling QEMU configured with --static, I've been getting configure errors like the following: Build-time dependency glib-2.0 found: NO ../target/hexagon/meson.build:303:15: ERROR: Dependency lookup for glib-2.0 with method 'pkgconfig' failed: Could not generate libs for glib-2.0: Package libpcre2-8 was not found in the pkg-config search path. Perhaps you should add the directory containing `libpcre2-8.pc' to the PKG_CONFIG_PATH environment variable Package 'libpcre2-8', required by 'glib-2.0', not found This happens because --static sets the prefer_static Meson option, but my build machine doesn't have a static libpcre2. I don't think it makes sense to insist that native dependencies are static, just because I want the non-native QEMU binaries to be static. Signed-off-by: Alyssa Ross <hi@alyssa.is> Link: https://lore.kernel.org/r/20240805104921.4035256-1-hi@alyssa.is Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit fe68cc0923ebfa0c12e4176f61ec9b363a07a73a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28module: Prevent crash by resetting local_err in module_load_qom_all()Alexander Ivanov
Set local_err to NULL after it has been freed in error_report_err(). This avoids triggering assert(*errp == NULL) failure in error_setv() when local_err is reused in the loop. Signed-off-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com> Reviewed-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Denis V. Lunev <den@openvz.org> Link: https://lore.kernel.org/r/20240809121340.992049-2-alexander.ivanov@virtuozzo.com [Do the same by moving the declaration instead. - Paolo] Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 940d802b24e63650e0eacad3714e2ce171cba17c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/arm: Clear high SVE elements in handle_vec_simd_wshliRichard Henderson
AdvSIMD instructions are supposed to zero bits beyond 128. Affects SSHLL, USHLL, SSHLL2, USHLL2. Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240717060903.205098-15-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 8e0c9a9efa21a16190cbac288e414bbf1d80f639) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/i386: Do not apply REX to MMX operandsRichard Henderson
Cc: qemu-stable@nongnu.org Fixes: b3e22b2318a ("target/i386: add core of new i386 decoder") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2495 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20240812025844.58956-2-richard.henderson@linaro.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 416f2b16c02c618c0f233372ebfe343f9ee667d4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28block/blkio: use FUA flag on write zeroes only if supportedStefano Garzarella
libblkio supports BLKIO_REQ_FUA with write zeros requests only since version 1.4.0, so let's inform the block layer that the blkio driver supports it only in this case. Otherwise we can have runtime errors as reported in https://issues.redhat.com/browse/RHEL-32878 Fixes: fd66dbd424 ("blkio: add libblkio block driver") Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-32878 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240808080545.40744-1-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 547c4e50929ec6c091d9c16a7b280e829b12b463) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/core/ptimer: fix timer zero period condition for freq > 1GHzJianzhou Yue
The real period is zero when both period and period_frac are zero. Check the method ptimer_set_freq, if freq is larger than 1000 MHz, the period is zero, but the period_frac is not, in this case, the ptimer will work but the current code incorrectly recognizes that the ptimer is disabled. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2306 Signed-off-by: JianZhou Yue <JianZhou.Yue@verisilicon.com> Message-id: 3DA024AEA8B57545AF1B3CAA37077D0FB75E82C8@SHASXM03.verisilicon.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 446e5e8b4515e9a7be69ef6a29852975289bb6f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28nbd/server: CVE-2024-7409: Avoid use-after-free when closing serverEric Blake
Commit 3e7ef738 plugged the use-after-free of the global nbd_server object, but overlooked a use-after-free of nbd_server->listener. Although this race is harder to hit, notice that our shutdown path first drops the reference count of nbd_server->listener, then triggers actions that can result in a pending client reaching the nbd_blockdev_client_closed() callback, which in turn calls qio_net_listener_set_client_func on a potentially stale object. If we know we don't want any more clients to connect, and have already told the listener socket to shut down, then we should not be trying to update the listener socket's associated function. Reproducer: > #!/usr/bin/python3 > > import os > from threading import Thread > > def start_stop(): > while 1: > os.system('virsh qemu-monitor-command VM \'{"execute": "nbd-server-start", +"arguments":{"addr":{"type":"unix","data":{"path":"/tmp/nbd-sock"}}}}\'') > os.system('virsh qemu-monitor-command VM \'{"execute": "nbd-server-stop"}\'') > > def nbd_list(): > while 1: > os.system('/path/to/build/qemu-nbd -L -k /tmp/nbd-sock') > > def test(): > sst = Thread(target=start_stop) > sst.start() > nlt = Thread(target=nbd_list) > nlt.start() > > sst.join() > nlt.join() > > test() Fixes: CVE-2024-7409 Fixes: 3e7ef738c8 ("nbd/server: CVE-2024-7409: Close stray clients at server-stop") CC: qemu-stable@nongnu.org Reported-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240822143617.800419-2-eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 3874f5f73c441c52f1c699c848d463b0eda01e4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28nbd/server: CVE-2024-7409: Close stray clients at server-stopEric Blake
A malicious client can attempt to connect to an NBD server, and then intentionally delay progress in the handshake, including if it does not know the TLS secrets. Although the previous two patches reduce this behavior by capping the default max-connections parameter and killing slow clients, they did not eliminate the possibility of a client waiting to close the socket until after the QMP nbd-server-stop command is executed, at which point qemu would SEGV when trying to dereference the NULL nbd_server global which is no longer present. This amounts to a denial of service attack. Worse, if another NBD server is started before the malicious client disconnects, I cannot rule out additional adverse effects when the old client interferes with the connection count of the new server (although the most likely is a crash due to an assertion failure when checking nbd_server->connections > 0). For environments without this patch, the CVE can be mitigated by ensuring (such as via a firewall) that only trusted clients can connect to an NBD server. Note that using frameworks like libvirt that ensure that TLS is used and that nbd-server-stop is not executed while any trusted clients are still connected will only help if there is also no possibility for an untrusted client to open a connection but then stall on the NBD handshake. Given the previous patches, it would be possible to guarantee that no clients remain connected by having nbd-server-stop sleep for longer than the default handshake deadline before finally freeing the global nbd_server object, but that could make QMP non-responsive for a long time. So intead, this patch fixes the problem by tracking all client sockets opened while the server is running, and forcefully closing any such sockets remaining without a completed handshake at the time of nbd-server-stop, then waiting until the coroutines servicing those sockets notice the state change. nbd-server-stop now has a second AIO_WAIT_WHILE_UNLOCKED (the first is indirectly through the blk_exp_close_all_type() that disconnects all clients that completed handshakes), but forced socket shutdown is enough to progress the coroutines and quickly tear down all clients before the server is freed, thus finally fixing the CVE. This patch relies heavily on the fact that nbd/server.c guarantees that it only calls nbd_blockdev_client_closed() from the main loop (see the assertion in nbd_client_put() and the hoops used in nbd_client_put_nonzero() to achieve that); if we did not have that guarantee, we would also need a mutex protecting our accesses of the list of connections to survive re-entrancy from independent iothreads. Although I did not actually try to test old builds, it looks like this problem has existed since at least commit 862172f45c (v2.12.0, 2017) - even back when that patch started using a QIONetListener to handle listening on multiple sockets, nbd_server_free() was already unaware that the nbd_blockdev_client_closed callback can be reached later by a client thread that has not completed handshakes (and therefore the client's socket never got added to the list closed in nbd_export_close_all), despite that patch intentionally tearing down the QIONetListener to prevent new clients. Reported-by: Alexander Ivanov <alexander.ivanov@virtuozzo.com> Fixes: CVE-2024-7409 CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240807174943.771624-14-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> (cherry picked from commit 3e7ef738c8462c45043a1d39f702a0990406a3b3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28nbd/server: CVE-2024-7409: Drop non-negotiating clientsEric Blake
A client that opens a socket but does not negotiate is merely hogging qemu's resources (an open fd and a small amount of memory); and a malicious client that can access the port where NBD is listening can attempt a denial of service attack by intentionally opening and abandoning lots of unfinished connections. The previous patch put a default bound on the number of such ongoing connections, but once that limit is hit, no more clients can connect (including legitimate ones). The solution is to insist that clients complete handshake within a reasonable time limit, defaulting to 10 seconds. A client that has not successfully completed NBD_OPT_GO by then (including the case of where the client didn't know TLS credentials to even reach the point of NBD_OPT_GO) is wasting our time and does not deserve to stay connected. Later patches will allow fine-tuning the limit away from the default value (including disabling it for doing integration testing of the handshake process itself). Note that this patch in isolation actually makes it more likely to see qemu SEGV after nbd-server-stop, as any client socket still connected when the server shuts down will now be closed after 10 seconds rather than at the client's whims. That will be addressed in the next patch. For a demo of this patch in action: $ qemu-nbd -f raw -r -t -e 10 file & $ nbdsh --opt-mode -c ' H = list() for i in range(20): print(i) H.insert(i, nbd.NBD()) H[i].set_opt_mode(True) H[i].connect_uri("nbd://localhost") ' $ kill $! where later connections get to start progressing once earlier ones are forcefully dropped for taking too long, rather than hanging. Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240807174943.771624-13-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [eblake: rebase to changes earlier in series, reduce scope of timer] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit b9b72cb3ce15b693148bd09cef7e50110566d8a0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28nbd/server: CVE-2024-7409: Cap default max-connections to 100Eric Blake
Allowing an unlimited number of clients to any web service is a recipe for a rudimentary denial of service attack: the client merely needs to open lots of sockets without closing them, until qemu no longer has any more fds available to allocate. For qemu-nbd, we default to allowing only 1 connection unless more are explicitly asked for (-e or --shared); this was historically picked as a nice default (without an explicit -t, a non-persistent qemu-nbd goes away after a client disconnects, without needing any additional follow-up commands), and we are not going to change that interface now (besides, someday we want to point people towards qemu-storage-daemon instead of qemu-nbd). But for qemu proper, and the newer qemu-storage-daemon, the QMP nbd-server-start command has historically had a default of unlimited number of connections, in part because unlike qemu-nbd it is inherently persistent until nbd-server-stop. Allowing multiple client sockets is particularly useful for clients that can take advantage of MULTI_CONN (creating parallel sockets to increase throughput), although known clients that do so (such as libnbd's nbdcopy) typically use only 8 or 16 connections (the benefits of scaling diminish once more sockets are competing for kernel attention). Picking a number large enough for typical use cases, but not unlimited, makes it slightly harder for a malicious client to perform a denial of service merely by opening lots of connections withot progressing through the handshake. This change does not eliminate CVE-2024-7409 on its own, but reduces the chance for fd exhaustion or unlimited memory usage as an attack surface. On the other hand, by itself, it makes it more obvious that with a finite limit, we have the problem of an unauthenticated client holding 100 fds opened as a way to block out a legitimate client from being able to connect; thus, later patches will further add timeouts to reject clients that are not making progress. This is an INTENTIONAL change in behavior, and will break any client of nbd-server-start that was not passing an explicit max-connections parameter, yet expects more than 100 simultaneous connections. We are not aware of any such client (as stated above, most clients aware of MULTI_CONN get by just fine on 8 or 16 connections, and probably cope with later connections failing by relying on the earlier connections; libvirt has not yet been passing max-connections, but generally creates NBD servers with the intent for a single client for the sake of live storage migration; meanwhile, the KubeSAN project anticipates a large cluster sharing multiple clients [up to 8 per node, and up to 100 nodes in a cluster], but it currently uses qemu-nbd with an explicit --shared=0 rather than qemu-storage-daemon with nbd-server-start). We considered using a deprecation period (declare that omitting max-parameters is deprecated, and make it mandatory in 3 releases - then we don't need to pick an arbitrary default); that has zero risk of breaking any apps that accidentally depended on more than 100 connections, and where such breakage might not be noticed under unit testing but only under the larger loads of production usage. But it does not close the denial-of-service hole until far into the future, and requires all apps to change to add the parameter even if 100 was good enough. It also has a drawback that any app (like libvirt) that is accidentally relying on an unlimited default should seriously consider their own CVE now, at which point they are going to change to pass explicit max-connections sooner than waiting for 3 qemu releases. Finally, if our changed default breaks an app, that app can always pass in an explicit max-parameters with a larger value. It is also intentional that the HMP interface to nbd-server-start is not changed to expose max-connections (any client needing to fine-tune things should be using QMP). Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240807174943.771624-12-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [ericb: Expand commit message to summarize Dan's argument for why we break corner-case back-compat behavior without a deprecation period] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit c8a76dbd90c2f48df89b75bef74917f90a59b623) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28nbd/server: Plumb in new args to nbd_client_add()Eric Blake
Upcoming patches to fix a CVE need to track an opaque pointer passed in by the owner of a client object, as well as request for a time limit on how fast negotiation must complete. Prepare for that by changing the signature of nbd_client_new() and adding an accessor to get at the opaque pointer, although for now the two servers (qemu-nbd.c and blockdev-nbd.c) do not change behavior even though they pass in a new default timeout value. Suggested-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Signed-off-by: Eric Blake <eblake@redhat.com> Message-ID: <20240807174943.771624-11-eblake@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [eblake: s/LIMIT/MAX_SECS/ as suggested by Dan] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit fb1c2aaa981e0a2fa6362c9985f1296b74f055ac) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28iotests: Add `vvfat` testsAmjad Alsharafi
Added several tests to verify the implementation of the vvfat driver. We needed a way to interact with it, so created a basic `fat16.py` driver that handled writing correct sectors for us. Added `vvfat` to the non-generic formats, as its not a normal image format. Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <bb8149c945301aefbdf470a0924c07f69f9c087d.1721470238.git.amjadsharafi10@gmail.com> [kwolf: Made mypy and pylint happy to unbreak 297] Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit c8f60bfb4345ea8343a53eaefe88d47b44c53f24) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28vvfat: Fix reading files with non-continuous clustersAmjad Alsharafi
When reading with `read_cluster` we get the `mapping` with `find_mapping_for_cluster` and then we call `open_file` for this mapping. The issue appear when its the same file, but a second cluster that is not immediately after it, imagine clusters `500 -> 503`, this will give us 2 mappings one has the range `500..501` and another `503..504`, both point to the same file, but different offsets. When we don't open the file since the path is the same, we won't assign `s->current_mapping` and thus accessing way out of bound of the file. From our example above, after `open_file` (that didn't open anything) we will get the offset into the file with `s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will give us `0x2000 * (504-500)`, which is out of bound for this mapping and will produce some issues. Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com> Message-ID: <1f3ea115779abab62ba32c788073cdc99f9ad5dd.1721470238.git.amjadsharafi10@gmail.com> [kwolf: Simplified the patch based on Amjad's analysis and input] Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 5eed3db336506b529b927ba221fe0d836e5b8819) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28vvfat: Fix wrong checks for cluster mappings invariantAmjad Alsharafi
How this `abort` was intended to check for was: - if the `mapping->first_mapping_index` is not the same as `first_mapping_index`, which **should** happen only in one case, when we are handling the first mapping, in that case `mapping->first_mapping_index == -1`, in all other cases, the other mappings after the first should have the condition `true`. - From above, we know that this is the first mapping, so if the offset is not `0`, then abort, since this is an invalid state. The issue was that `first_mapping_index` is not set if we are checking from the middle, the variable `first_mapping_index` is only set if we passed through the check `cluster_was_modified` with the first mapping, and in the same function call we checked the other mappings. One approach is to go into the loop even if `cluster_was_modified` is not true so that we will be able to set `first_mapping_index` for the first mapping, but since `first_mapping_index` is only used here, another approach is to just check manually for the `mapping->first_mapping_index != -1` since we know that this is the value for the only entry where `offset == 0` (i.e. first mapping). Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <b0fbca3ee208c565885838f6a7deeaeb23f4f9c2.1721470238.git.amjadsharafi10@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit f60a6f7e17bf2a2a0f0a08265ac9b077fce42858) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28vvfat: Fix usage of `info.file.offset`Amjad Alsharafi
The field is marked as "the offset in the file (in clusters)", but it was being used like this `cluster_size*(nums)+mapping->info.file.offset`, which is incorrect. Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <72f19a7903886dda1aa78bcae0e17702ee939262.1721470238.git.amjadsharafi10@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 21b25a0e466a5bba0a45600bb8100ab564202ed1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28vvfat: Fix bug in writing to middle of fileAmjad Alsharafi
Before this commit, the behavior when calling `commit_one_file` for example with `offset=0x2000` (second cluster), what will happen is that we won't fetch the next cluster from the fat, and instead use the first cluster for the read operation. This is due to off-by-one error here, where `i=0x2000 !< offset=0x2000`, thus not fetching the next cluster. Signed-off-by: Amjad Alsharafi <amjadsharafi10@gmail.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <b97c1e1f1bc2f776061ae914f95d799d124fcd73.1721470238.git.amjadsharafi10@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit b881cf00c99e03bc8a3648581f97736ff275b18b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/sd/sdhci: Reset @data_count index on invalid ADMA transfersPhilippe Mathieu-Daudé
We neglected to clear the @data_count index on ADMA error, allowing to trigger assertion in sdhci_read_dataport() or sdhci_write_dataport(). Cc: qemu-stable@nongnu.org Fixes: d7dfca0807 ("hw/sdhci: introduce standard SD host controller") Reported-by: Zheyu Ma <zheyuma97@gmail.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2455 Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20240730092138.32443-4-philmd@linaro.org> (cherry picked from commit ed5a159c3de48a581f46de4c8c02b4b295e6c52d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/i386: Fix VSIB decodeRichard Henderson
With normal SIB, index == 4 indicates no index. With VSIB, there is no exception for VR4/VR12. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2474 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Link: https://lore.kernel.org/r/20240805003130.1421051-3-richard.henderson@linaro.org Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ac63755b20013ec6a3d2aef4538d37dc90bc3d10) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: modify the change to pre-new-decoder introduced past qemu 9.0)
2024-08-28virtio-net: Fix network stall at the host side waiting for kickthomas
Patch 06b12970174 ("virtio-net: fix network stall under load") added double-check to test whether the available buffer size can satisfy the request or not, in case the guest has added some buffers to the avail ring simultaneously after the first check. It will be lucky if the available buffer size becomes okay after the double-check, then the host can send the packet to the guest. If the buffer size still can't satisfy the request, even if the guest has added some buffers, viritio-net would stall at the host side forever. The patch enables notification and checks whether the guest has added some buffers since last check of available buffers when the available buffers are insufficient. If no buffer is added, return false, else recheck the available buffers in the loop. If the available buffers are sufficient, disable notification and return true. Changes: 1. Change the return type of virtqueue_get_avail_bytes() from void to int, it returns an opaque that represents the shadow_avail_idx of the virtqueue on success, else -1 on error. 2. Add a new API: virtio_queue_enable_notification_and_check(), it takes an opaque as input arg which is returned from virtqueue_get_avail_bytes(). It enables notification firstly, then checks whether the guest has added some buffers since last check of available buffers or not by virtio_queue_poll(), return ture if yes. The patch also reverts patch "06b12970174". The case below can reproduce the stall. Guest 0 +--------+ | iperf | ---------------> | server | Host | +--------+ +--------+ | ... | iperf |---- | client |---- Guest n +--------+ | +--------+ | | iperf | ---------------> | server | +--------+ Boot many guests from qemu with virtio network: qemu ... -netdev tap,id=net_x \ -device virtio-net-pci-non-transitional,\ iommu_platform=on,mac=xx:xx:xx:xx:xx:xx,netdev=net_x Each guest acts as iperf server with commands below: iperf3 -s -D -i 10 -p 8001 iperf3 -s -D -i 10 -p 8002 The host as iperf client: iperf3 -c guest_IP -p 8001 -i 30 -w 256k -P 20 -t 40000 iperf3 -c guest_IP -p 8002 -i 30 -w 256k -P 20 -t 40000 After some time, the host loses connection to the guest, the guest can send packet to the host, but can't receive packet from the host. It's more likely to happen if SWIOTLB is enabled in the guest, allocating and freeing bounce buffer takes some CPU ticks, copying from/to bounce buffer takes more CPU ticks, compared with that there is no bounce buffer in the guest. Once the rate of producing packets from the host approximates the rate of receiveing packets in the guest, the guest would loop in NAPI. receive packets --- | | v | free buf virtnet_poll | | v | add buf to avail ring --- | | need kick the host? | NAPI continues v receive packets --- | | v | free buf virtnet_poll | | v | add buf to avail ring --- | v ... ... On the other hand, the host fetches free buf from avail ring, if the buf in the avail ring is not enough, the host notifies the guest the event by writing the avail idx read from avail ring to the event idx of used ring, then the host goes to sleep, waiting for the kick signal from the guest. Once the guest finds the host is waiting for kick singal (in virtqueue_kick_prepare_split()), it kicks the host. The host may stall forever at the sequences below: Host Guest ------------ ----------- fetch buf, send packet receive packet --- ... ... | fetch buf, send packet add buf | ... add buf virtnet_poll buf not enough avail idx-> add buf | read avail idx add buf | add buf --- receive packet --- write event idx ... | wait for kick add buf virtnet_poll ... | --- no more packet, exit NAPI In the first loop of NAPI above, indicated in the range of virtnet_poll above, the host is sending packets while the guest is receiving packets and adding buffers. step 1: The buf is not enough, for example, a big packet needs 5 buf, but the available buf count is 3. The host read current avail idx. step 2: The guest adds some buf, then checks whether the host is waiting for kick signal, not at this time. The used ring is not empty, the guest continues the second loop of NAPI. step 3: The host writes the avail idx read from avail ring to used ring as event idx via virtio_queue_set_notification(q->rx_vq, 1). step 4: At the end of the second loop of NAPI, recheck whether kick is needed, as the event idx in the used ring written by the host is beyound the range of kick condition, the guest will not send kick signal to the host. Fixes: 06b12970174 ("virtio-net: fix network stall under load") Cc: qemu-stable@nongnu.org Signed-off-by: Wencheng Yang <east.moutain.yang@gmail.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit f937309fbdbb48c354220a3e7110c202ae4aa7fa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in include/hw/virtio/virtio.h)
2024-08-28virtio-net: Ensure queue index fits with RSSAkihiko Odaki
Ensure the queue index points to a valid queue when software RSS enabled. The new calculation matches with the behavior of Linux's TAP device with the RSS eBPF program. Fixes: 4474e37a5b3a ("virtio-net: implement RX RSS processing") Reported-by: Zhibin Hu <huzhibin5@huawei.com> Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit f1595ceb9aad36a6c1da95bcb77ab9509b38822d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Fixes: CVE-2024-6505
2024-08-28target/arm: Handle denormals correctly for FMOPA (widening)Peter Maydell
The FMOPA (widening) SME instruction takes pairs of half-precision floating point values, widens them to single-precision, does a two-way dot product and accumulates the results into a single-precision destination. We don't quite correctly handle the FPCR bits FZ and FZ16 which control flushing of denormal inputs and outputs. This is because at the moment we pass a single float_status value to the helper function, which then uses that configuration for all the fp operations it does. However, because the inputs to this operation are float16 and the outputs are float32 we need to use the fp_status_f16 for the float16 input widening but the normal fp_status for everything else. Otherwise we will apply the flushing control FPCR.FZ16 to the 32-bit output rather than the FPCR.FZ control, and incorrectly flush a denormal output to zero when we should not (or vice-versa). (In commit 207d30b5fdb5b we tried to fix the FZ handling but didn't get it right, switching from "use FPCR.FZ for everything" to "use FPCR.FZ16 for everything".) (Mjt: it is commit 4975f9fc4ea3 in stable-8.2) Pass the CPU env to the sme_fmopa_h helper instead of an fp_status pointer, and have the helper pass an extra fp_status into the f16_dotadd() function so that we can use the right status for the right parts of this operation. Cc: qemu-stable@nongnu.org Fixes: 207d30b5fdb5 ("target/arm: Use FPST_F16 for SME FMOPA (widening)") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2373 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 55f9f4ee018c5ccea81d8c8c586756d7711ae46f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/arm/mps2-tz.c: fix RX/TX interrupts orderMarco Palumbi
The order of the RX and TX interrupts are swapped. This commit fixes the order as per the following documents: * https://developer.arm.com/documentation/dai0505/latest/ * https://developer.arm.com/documentation/dai0521/latest/ * https://developer.arm.com/documentation/dai0524/latest/ * https://developer.arm.com/documentation/dai0547/latest/ Cc: qemu-stable@nongnu.org Signed-off-by: Marco Palumbi <Marco.Palumbi@tii.ae> Message-id: 20240730073123.72992-1-marco@palumbi.it Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 5a558be93ad628e5bed6e0ee062870f49251725c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/i386/amd_iommu: Don't leak memory in amdvi_update_iotlb()Peter Maydell
In amdvi_update_iotlb() we will only put a new entry in the hash table if to_cache.perm is not IOMMU_NONE. However we allocate the memory for the new AMDVIIOTLBEntry and for the hash table key regardless. This means that in the IOMMU_NONE case we will leak the memory we alloacted. Move the allocations into the if() to the point where we know we're going to add the item to the hash table. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2452 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240731170019.3590563-1-peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 9a45b0761628cc59267b3283a85d15294464ac31) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28docs/sphinx/depfile.py: Handle env.doc2path() returning a Path not a strPeter Maydell
In newer versions of Sphinx the env.doc2path() API is going to change to return a Path object rather than a str. This was originally visible in Sphinx 8.0.0rc1, but has been rolled back for the final 8.0.0 release. However it will probably emit a deprecation warning and is likely to change for good in 9.0: https://github.com/sphinx-doc/sphinx/issues/12686 Our use in depfile.py assumes a str, and if it is passed a Path it will fall over: Handler <function write_depfile at 0x77a1775ff560> for event 'build-finished' threw an exception (exception: unsupported operand type(s) for +: 'PosixPath' and 'str') Wrapping the env.doc2path() call in str() will coerce a Path object to the str we expect, and have no effect in older Sphinx versions that do return a str. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2458 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240729120533.2486427-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 48e5b5f994bccf161dd88a67fdd819d4bfb400f1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/arm: Ignore SMCR_EL2.LEN and SVCR_EL2.LEN if EL2 is not enabledPeter Maydell
When determining the current vector length, the SMCR_EL2.LEN and SVCR_EL2.LEN settings should only be considered if EL2 is enabled (compare the pseudocode CurrentSVL and CurrentNSVL which call EL2Enabled()). We were checking against ARM_FEATURE_EL2 rather than calling arm_is_el2_enabled(), which meant that we would look at SMCR_EL2/SVCR_EL2 when in Secure EL1 or Secure EL0 even if Secure EL2 was not enabled. Use the correct check in sve_vqm1_for_el_sm(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240722172957.1041231-5-peter.maydell@linaro.org (cherry picked from commit f573ac059ed060234fcef4299fae9e500d357c33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/arm: Avoid shifts by -1 in tszimm_shr() and tszimm_shl()Peter Maydell
The function tszimm_esz() returns a shift amount, or possibly -1 in certain cases that correspond to unallocated encodings in the instruction set. We catch these later in the trans_ functions (generally with an "a-esz < 0" check), but before we do the decodetree-generated code will also call tszimm_shr() or tszimm_sl(), which will use the tszimm_esz() return value as a shift count without checking that it is not negative, which is undefined behaviour. Avoid the UB by checking the return value in tszimm_shr() and tszimm_shl(). Cc: qemu-stable@nongnu.org Resolves: Coverity CID 1547617, 1547694 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240722172957.1041231-4-peter.maydell@linaro.org (cherry picked from commit 76916dfa89e8900639c1055c07a295c06628a0bc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/arm: Fix UMOPA/UMOPS of 16-bit valuesPeter Maydell
The UMOPA/UMOPS instructions are supposed to multiply unsigned 8 or 16 bit elements and accumulate the products into a 64-bit element. In the Arm ARM pseudocode, this is done with the usual infinite-precision signed arithmetic. However our implementation doesn't quite get it right, because in the DEF_IMOP_64() macro we do: sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); where NTYPE and MTYPE are uint16_t or int16_t. In the uint16_t case, the C usual arithmetic conversions mean the values are converted to "int" type and the multiply is done as a 32-bit multiply. This means that if the inputs are, for example, 0xffff and 0xffff then the result is 0xFFFE0001 as an int, which is then promoted to uint64_t for the accumulation into sum; this promotion incorrectly sign extends the multiply. Avoid the incorrect sign extension by casting to int64_t before the multiply, so we do the multiply as 64-bit signed arithmetic, which is a type large enough that the multiply can never overflow into the sign bit. (The equivalent 8-bit operations in DEF_IMOP_32() are fine, because the 8-bit multiplies can never overflow into the sign bit of a 32-bit integer.) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2372 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240722172957.1041231-3-peter.maydell@linaro.org (cherry picked from commit ea3f5a90f036734522e9af3bffd77e69e9f47355) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/arm: Don't assert for 128-bit tile accesses when SVL is 128Peter Maydell
For an instruction which accesses a 128-bit element tile when the SVL is also 128 (for example MOV z0.Q, p0/M, ZA0H.Q[w0,0]), we will assert in get_tile_rowcol(): qemu-system-aarch64: ../../tcg/tcg-op.c:926: tcg_gen_deposit_z_i32: Assertion `len > 0' failed. This happens because we calculate len = ctz32(streaming_vec_reg_size(s)) - esz;$ but if the SVL and the element size are the same len is 0, and the deposit operation asserts. In this case the ZA storage contains exactly one 128 bit element ZA tile, and the horizontal or vertical slice is just that tile. This means that regardless of the index value in the Ws register, we always access that tile. (In pseudocode terms, we calculate (index + offset) MOD 1, which is 0.) Special case the len == 0 case to avoid hitting the assertion in tcg_gen_deposit_z_i32(). Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240722172957.1041231-2-peter.maydell@linaro.org (cherry picked from commit 56f1c0db928aae0b83fd91c89ddb226b137e2b21) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28hw/misc/bcm2835_property: Fix handling of FRAMEBUFFER_SET_PALETTEPeter Maydell
The documentation of the "Set palette" mailbox property at https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#set-palette says it has the form: Length: 24..1032 Value: u32: offset: first palette index to set (0-255) u32: length: number of palette entries to set (1-256) u32...: RGBA palette values (offset to offset+length-1) We get this wrong in a couple of ways: * we aren't checking the offset and length are in range, so the guest can make us spin for a long time by providing a large length * the bounds check on our loop is wrong: we should iterate through 'length' palette entries, not 'length - offset' entries Fix the loop to implement the bounds checks and get the loop condition right. In the process, make the variables local to this switch case, rather than function-global, so it's clearer what type they are when reading the code. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240723131029.1159908-2-peter.maydell@linaro.org (cherry picked from commit 0892fffc2abaadfb5d8b79bb0250ae1794862560) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix due to lack of v9.0.0-1812-g5d5f1b60916a "hw/misc: Implement mailbox properties for customer OTP and device specific private keys" also remove now-unused local `n' variable which gets removed in the next change in this file, v9.0.0-2720-g32f1c201eedf "hw/misc/bcm2835_property: Avoid overflow in OTP access properties")
2024-08-28hw/char/bcm2835_aux: Fix assert when receive FIFO fills upFrederik van Hövell
When a bare-metal application on the raspi3 board reads the AUX_MU_STAT_REG MMIO register while the device's buffer is at full receive FIFO capacity (i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)` fails. Reported-by: Cryptjar <cryptjar@junk.studio> Suggested-by: Cryptjar <cryptjar@junk.studio> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/459 Signed-off-by: Frederik van Hövell <frederik@fvhovell.nl> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> [PMM: commit message tweaks] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 546d574b11e02bfd5b15cdf1564842c14516dfab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-08-28target/rx: Use target_ulong for address in LIRichard Henderson
Using int32_t meant that the address was sign-extended to uint64_t when passing to translator_ld*, triggering an assert. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2453 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 83340193b991e7a974f117baa86a04db1fd835a9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-24 00:18:14 +0000