aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-04target/ppc: Disable goto_tb with architectural singlestepRichard Henderson1-0/+3
The change to use translator_use_goto_tb went too far, as the CF_SINGLE_STEP flag managed by the translator only handles gdb single stepping and not the architectural single stepping modeled in DisasContext.singlestep_enabled. Fixes: 6e9cc373ec5 ("target/ppc: Use translator_use_goto_tb") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1795 Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 2e718e665706d5fcc3e3501bda26f277f055ed85) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-04util/interval-tree: Use qatomic_set_mb in rb_link_nodeRichard Henderson1-1/+5
Ensure that the stores to rb_left and rb_right are complete before inserting the new node into the tree. Otherwise a concurrent reader could see garbage in the new leaf. Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 4c8baa02d36379507afd17bdea87aabe0aa32ed3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: s/qatomic_set_mb/qatomic_mb_set/ for 8.0 - it was renamed later)
2023-08-01util/interval-tree: Use qatomic_read for left/right while searchingRichard Henderson1-6/+9
Fixes a race condition (generally without optimization) in which the subtree is re-read after the protecting if condition. Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 055b86e0f0b4325117055d8d31c49011258f4af3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/arm: Avoid writing to constant TCGv in trans_CSEL()Peter Maydell1-7/+8
In commit 0b188ea05acb5 we changed the implementation of trans_CSEL() to use tcg_constant_i32(). However, this change was incorrect, because the implementation of the function sets up the TCGv_i32 rn and rm to be either zero or else a TCG temp created in load_reg(), and these TCG temps are then in both cases written to by the emitted TCG ops. The result is that we hit a TCG assertion: qemu-system-arm: ../../tcg/tcg.c:4455: tcg_reg_alloc_mov: Assertion `!temp_readonly(ots)' failed. (or on a non-debug build, just produce a garbage result) Adjust the code so that rn and rm are always writeable temporaries whether the instruction is using the special case "0" or a normal register as input. Cc: qemu-stable@nongnu.org Fixes: 0b188ea05acb5 ("target/arm: Use tcg_constant in trans_CSEL") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230727103906.2641264-1-peter.maydell@linaro.org (cherry picked from commit 2b0d656ab6484cae7f174e194215a6d50343ecd2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/arm: Special case M-profile in debug_helper.c codePeter Maydell1-6/+12
A lot of the code called from helper_exception_bkpt_insn() is written assuming A-profile, but we will also call this helper on M-profile CPUs when they execute a BKPT insn. This used to work by accident, but recent changes mean that we will hit an assert when some of this code calls down into lower level functions that end up calling arm_security_space_below_el3(), arm_el_is_aa64(), and other functions that now explicitly assert that the guest CPU is not M-profile. Handle M-profile directly to avoid the assertions: * in arm_debug_target_el(), M-profile debug exceptions always go to EL1 * in arm_debug_exception_fsr(), M-profile always uses the short format FSR (compare commit d7fe699be54b2, though in this case the code in arm_v7m_cpu_do_interrupt() does not need to look at the FSR value at all) Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1775 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230721143239.1753066-1-peter.maydell@linaro.org (cherry picked from commit 5d78893f39caf94c8587141e2219b57a7d63dd5c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31hw/arm/smmu: Handle big-endian hosts correctlyPeter Maydell2-10/+32
The implementation of the SMMUv3 has multiple places where it reads a data structure from the guest and directly operates on it without doing a guest-to-host endianness conversion. Since all SMMU data structures are little-endian, this means that the SMMU doesn't work on a big-endian host. In particular, this causes the Avocado test machine_aarch64_virt.py:Aarch64VirtMachine.test_alpine_virt_tcg_gic_max to fail on an s390x host. Add appropriate byte-swapping on reads and writes of guest in-memory data structures so that the device works correctly on big-endian hosts. As part of this we constrain queue_read() to operate only on Cmd structs and queue_write() on Evt structs, because in practice these are the only data structures the two functions are used with, and we need to know what the data structure is to be able to byte-swap its parts correctly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20230717132641.764660-1-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org (cherry picked from commit c6445544d4cea2628fbad3bad09f3d3a03c749d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31virtio-net: pass Device-TLB enable/disable events to vhostViktor Prutyanov1-0/+1
If vhost is enabled for virtio-net, Device-TLB enable/disable events must be passed to vhost for proper IOMMU unmap flag selection. Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230626091258.24453-3-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit cd9b8346884353ba9ae6560b44b7cccdf00a6633) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31vhost: register and change IOMMU flag depending on Device-TLB stateViktor Prutyanov3-12/+31
The guest can disable or never enable Device-TLB. In these cases, it can't be used even if enabled in QEMU. So, check Device-TLB state before registering IOMMU notifier and select unmap flag depending on that. Also, implement a way to change IOMMU notifier flag if Device-TLB state is changed. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2001312 Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20230626091258.24453-2-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit ee071f67f7a103c66f85f68ffe083712929122e3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31virtio-pci: add handling of PCI ATS and Device-TLB enable/disableViktor Prutyanov2-0/+38
According to PCIe Address Translation Services specification 5.1.3., ATS Control Register has Enable bit to enable/disable ATS. Guest may enable/disable PCI ATS and, accordingly, Device-TLB for the VirtIO PCI device. So, raise/lower a flag and call a trigger function to pass this event to a device implementation. Signed-off-by: Viktor Prutyanov <viktor@daynix.com> Message-Id: <20230512135122.70403-2-viktor@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 206e91d143301414df2deb48a411e402414ba6db) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/loongarch: Fix the CSRRD CPUID instruction on big endian hostsThomas Huth4-7/+12
The test in tests/avocado/machine_loongarch.py is currently failing on big endian hosts like s390x. By comparing the traces between running the QEMU_EFI.fd bios on a s390x and on a x86 host, it's quickly obvious that the CSRRD instruction for the CPUID is behaving differently. And indeed: The code currently does a long read (i.e. 64 bit) from the address that points to the CPUState->cpu_index field (with tcg_gen_ld_tl() in the trans_csrrd() function). But this cpu_index field is only an "int" (i.e. 32 bit). While this dirty pointer magic works on little endian hosts, it of course fails on big endian hosts. Fix it by using a proper helper function instead. Message-Id: <20230720175307.854460-1-thuth@redhat.com> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit c34ad459926f6c600a55fe6782a27edfa405d60b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix assertion failure in VFMIN/VFMAX with type 13Ilya Leoshkevich1-1/+1
Type 13 is reserved, so using it should result in specification exception. Due to an off-by-1 error the code triggers an assertion at a later point in time instead. Cc: qemu-stable@nongnu.org Fixes: da4807527f3b ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)") Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-8-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit ff537b0370ab5918052b8d8a798e803c47272406) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Make MC raise specification exception when class >= 16Ilya Leoshkevich2-3/+3
MC requires bit positions 8-11 (upper 4 bits of class) to be zeros, otherwise it must raise a specification exception. Cc: qemu-stable@nongnu.org Fixes: 20d143e2cab8 ("s390x/tcg: Implement MONITOR CALL") Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-6-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 9c028c057adce49304c6e4a51f6b426bd4f8f6b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix ICM with M3=0Ilya Leoshkevich1-0/+6
When the mask is zero, access exceptions should still be recognized for 1 byte at the second-operand address. CC should be set to 0. Cc: qemu-stable@nongnu.org Fixes: e023e832d0ac ("s390x: translate engine for s390x CPU") Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-5-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit a2025557ed4d8d5e6a4d0dd681717c390f51f5be) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix CONVERT TO LOGICAL/FIXED with out-of-range inputsIlya Leoshkevich1-1/+2
CONVERT TO LOGICAL/FIXED deviate from IEEE 754 in that they raise an inexact exception on out-of-range inputs. float_flag_invalid_cvti aligns nicely with that behavior, so convert it to S390_IEEE_MASK_INEXACT. Cc: qemu-stable@nongnu.org Fixes: defb0e3157af ("s390x: Implement opcode helpers") Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-4-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 53684e344a27da770acc9012740334154ddea24f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix CLM with M3=0Ilya Leoshkevich1-0/+5
When the mask is zero, access exceptions should still be recognized for 1 byte at the second-operand address. CC should be set to 0. Cc: qemu-stable@nongnu.org Fixes: defb0e3157af ("s390x: Implement opcode helpers") Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-3-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 4b6e4c0b8223681ae85462794848db4386de1a8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Make CKSM raise an exception if R2 is oddIlya Leoshkevich2-1/+7
R2 designates an even-odd register pair; the instruction should raise a specification exception when R2 is not even. Cc: qemu-stable@nongnu.org Fixes: e023e832d0ac ("s390x: translate engine for s390x CPU") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-Id: <20230724082032.66864-2-iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 761b0aa9381e2f755b9b594f7f3033d564561751) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31tcg/{i386, s390x}: Add earlyclobber to the op_add2's first outputIlya Leoshkevich5-8/+19
i386 and s390x implementations of op_add2 require an earlyclobber, which is currently missing. This breaks VCKSM in s390x guests. E.g., on x86_64 the following op: add2_i32 tmp2,tmp3,tmp2,tmp3,tmp3,tmp2 dead: 0 2 3 4 5 pref=none,0xffff is translated to: addl %ebx, %r12d adcl %r12d, %ebx Introduce a new C_N1_O1_I4 constraint, and make sure that earlyclobber of aliased outputs is honored. Cc: qemu-stable@nongnu.org Fixes: 82790a870992 ("tcg: Add markup for output requires new register") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230719221310.1968845-7-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 22d2e5351a18aff5a9c7e3984b50ecce61ff8975) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31tcg/ppc: Fix race in goto_tb implementationJordan Niethe1-4/+5
Commit 20b6643324 ("tcg/ppc: Reorg goto_tb implementation") modified goto_tb to ensure only a single instruction was patched to prevent incorrect behavior if a thread was in the middle of multiple instructions when they were replaced. However this introduced a race between loading the jmp target into TCG_REG_TB and patching and executing the direct branch. The relevant part of the goto_tb implementation: ld TCG_REG_TB, TARGET_ADDR_LOCATION(TCG_REG_TB) patch_location: mtctr TCG_REG_TB bctr tb_target_set_jmp_target() will replace 'patch_location' with a direct branch if the target is in range. The direct branch now relies on TCG_REG_TB being set up correctly by the ld. Prior to this commit multiple instructions were patched in for the direct branch case; these instructions would initialize TCG_REG_TB to the same value as the branch target. Imagine the following sequence: 1) Thread A is executing the goto_tb sequence and loads the jmp target into TCG_REG_TB. 2) Thread B updates the jmp target address and calls tb_target_set_jmp_target(). This patches a new direct branch into the goto_tb sequence. 3) Thread A executes the newly patched direct branch. The value in TCG_REG_TB still contains the old jmp target. TCG_REG_TB MUST contain the translation block's tc.ptr. Execution will eventually crash after performing memory accesses generated from a faulty value in TCG_REG_TB. This presents as segfaults or illegal instruction exceptions. Do not revert commit 20b6643324 as it did fix a different race condition. Instead remove the direct branch optimization and always use indirect branches. The direct branch optimization can be re-added later with a race free sequence. Fixes: 20b6643324 ("tcg/ppc: Reorg goto_tb implementation") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1726 Reported-by: Anushree Mathur <anushree.mathur@linux.vnet.ibm.com> Tested-by: Anushree Mathur <anushree.mathur@linux.vnet.ibm.com> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Co-developed-by: Benjamin Gray <bgray@linux.ibm.com> Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com> Message-Id: <20230717093001.13167-1-jniethe5@gmail.com> (cherry picked from commit 736a1588c104e9995c1831df33554df1f1def8b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31qemu-nbd: regression with arguments passing into nbd_client_thread()Denis V. Lunev1-1/+4
Unfortunately commit 03b67621445d601c9cdc7dfe25812e9f19b81488 (8.0: feb0814b3b48e75b336ad72eb303f9d579c94083) Author: Denis V. Lunev <den@openvz.org> Date: Mon Jul 17 16:55:40 2023 +0200 qemu-nbd: pass structure into nbd_client_thread instead of plain char* has introduced a regression. struct NbdClientOpts resides on stack inside 'if' block. This specifically means that this stack space could be reused once the execution will leave that block of the code. This means that parameters passed into nbd_client_thread could be overwritten at any moment. The patch moves the data to the namespace of main() function effectively preserving it for the whole process lifetime. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Eric Blake <eblake@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: <qemu-stable@nongnu.org> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20230727105828.324314-1-den@openvz.org> Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit e5b815b0defcc3617f473ba70c3e675ef0ee69c2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: add reference to feb0814b3b48e75b336ad72eb303f9d579c94083 for 8.0 branch)
2023-07-31qemu-nbd: fix regression with qemu-nbd --fork run over sshDenis V. Lunev1-9/+4
Commit e6df58a5578fee7a50bbf36f4a50a2781cff855d Author: Hanna Reitz <hreitz@redhat.com> Date: Wed May 8 23:18:18 2019 +0200 qemu-nbd: Do not close stderr has introduced an interesting regression. Original behavior of ssh somehost qemu-nbd /home/den/tmp/file -f raw --fork was the following: * qemu-nbd was started as a daemon * the command execution is done and ssh exited with success The patch has changed this behavior and 'ssh' command now hangs forever. According to the normal specification of the daemon() call, we should endup with STDERR pointing to /dev/null. That should be done at the very end of the successful startup sequence when the pipe to the bootstrap process (used for diagnostics) is no longer needed. This could be achived in the same way as done for 'qemu-nbd -c' case. That was commit 0eaf453e, also fixing up e6df58a5. STDOUT copying to STDERR does the trick. This also leads to proper 'ssh' connection closing which fixes my original problem. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Eric Blake <eblake@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: Hanna Reitz <hreitz@redhat.com> CC: <qemu-stable@nongnu.org> Message-ID: <20230717145544.194786-3-den@openvz.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 5c56dd27a2c905c9cf2472d2fd057621ce5fd00d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31qemu-nbd: pass structure into nbd_client_thread instead of plain char*Denis V. Lunev1-6/+13
We are going to pass additional flag inside next patch. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Eric Blake <eblake@redhat.com> CC: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> CC: <qemu-stable@nongnu.org> Message-ID: <20230717145544.194786-2-den@openvz.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 03b67621445d601c9cdc7dfe25812e9f19b81488) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Fix signed math overflow in brk() syscallHelge Deller1-2/+3
Fix the math overflow when calculating the new_malloc_size. new_host_brk_page and brk_page are unsigned integers. If userspace reduces the heap, new_host_brk_page is lower than brk_page which results in a huge positive number (but should actually be negative). Fix it by adding a proper check and as such make the code more readable. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: "Markus F.X.J. Oberhumer" <markus@oberhumer.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Fixes: 86f04735ac ("linux-user: Fix brk() to release pages") Cc: qemu-stable@nongnu.org Buglink: https://github.com/upx/upx/issues/683 (cherry picked from commit eac78a4b0b7da4de2c0a297f4d528ca9cc6256a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Prohibit brk() to to shrink below initial heap addressHelge Deller1-1/+7
Since commit 86f04735ac ("linux-user: Fix brk() to release pages") it's possible for userspace applications to reduce their memory footprint by calling brk() with a lower address and free up memory. Before that commit guest heap memory was never unmapped. But the Linux kernel prohibits to reduce brk() below the initial memory address which is set at startup by the set_brk() function in binfmt_elf.c. Such a range check was missed in commit 86f04735ac. This patch adds the missing check by storing the initial brk value in initial_target_brk and verify any new brk addresses against that value. Tested with the i386 upx binary from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-i386_linux.tar.xz Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: "Markus F.X.J. Oberhumer" <markus@oberhumer.com> Fixes: 86f04735ac ("linux-user: Fix brk() to release pages") Cc: qemu-stable@nongnu.org Buglink: https://github.com/upx/upx/issues/683 (cherry picked from commit dfe49864afb06e7e452a4366051697bc4fcfc1a5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Fix qemu brk() to not zero bytes on current pageHelge Deller1-6/+4
The qemu brk() implementation is too aggressive and cleans remaining bytes on the current page above the last brk address. But some existing applications are buggy and read/write bytes above their current heap address. On a phyiscal machine this does not trigger a runtime error as long as the access happens on the same page. Additionally the Linux kernel allocates only full pages and does no zeroing on already allocated pages, even if the brk address is lowered. Fix qemu to behave the same way as the kernel does. Do not touch already allocated pages, and - when running with different page sizes of guest and host - zero out only those memory areas where the host page size is bigger than the guest page size. Signed-off-by: Helge Deller <deller@gmx.de> Tested-by: "Markus F.X.J. Oberhumer" <markus@oberhumer.com> Fixes: 86f04735ac ("linux-user: Fix brk() to release pages") Cc: qemu-stable@nongnu.org Buglink: https://github.com/upx/upx/issues/683 (cherry picked from commit 15ad98536ad9410fb32ddf1ff09389b677643faa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31hw/nvme: fix endianness issue for shadow doorbellsKlaus Jensen1-5/+13
In commit 2fda0726e514 ("hw/nvme: fix missing endian conversions for doorbell buffers"), we fixed shadow doorbells for big-endian guests running on little endian hosts. But I did not fix little-endian guests on big-endian hosts. Fix this. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1765 Fixes: 3f7fe8de3d49 ("hw/nvme: Implement shadow doorbell buffer support") Cc: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Cédric Le Goater <clg@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com> (cherry picked from commit ea3c76f1494d0c75873c3b470e6e048202661ad8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Make sure initial brk(0) is page-alignedAndreas Schwab1-1/+1
Fixes: 86f04735ac ("linux-user: Fix brk() to release pages") Signed-off-by: Andreas Schwab <schwab@suse.de> Message-Id: <mvmpm55qnno.fsf@suse.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit d28b3c90cfad1a7e211ae2bce36ecb9071086129) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)Mauro Matteo Cascella1-6/+4
A wrong exit condition may lead to an infinite loop when inflating a valid zlib buffer containing some extra bytes in the `inflate_buffer` function. The bug only occurs post-authentication. Return the buffer immediately if the end of the compressed data has been reached (Z_STREAM_END). Fixes: CVE-2023-3255 Fixes: 0bf41cab ("ui/vnc: clipboard support") Reported-by: Kevin Denis <kevin.denis@synacktiv.com> Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230704084210.101822-1-mcascell@redhat.com> (cherry picked from commit d921fea338c1059a27ce7b75309d7a2e485f710b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user/arm: Do not allocate a commpage at all for M-profile CPUsPhilippe Mathieu-Daudé1-4/+17
Since commit fbd3c4cff6 ("linux-user/arm: Mark the commpage executable") executing bare-metal (linked with rdimon.specs) cortex-M code fails as: $ qemu-arm -cpu cortex-m3 ~/hello.exe.m3 qemu-arm: ../../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed. Aborted (core dumped) Commit 4f5c67f8df ("linux-user/arm: Take more care allocating commpage") already took care of not allocating a commpage for M-profile CPUs, however it had to be reverted as commit 6cda41daa2. Re-introduce the M-profile fix from commit 4f5c67f8df. Fixes: fbd3c4cff6 ("linux-user/arm: Mark the commpage executable") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1755 Reported-by: Christophe Lyon <christophe.lyon@linaro.org> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230711153408.68389-1-philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit d713cf4d6c71076513a10528303b3e337b4d5998) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31tcg: Fix info_in_idx increment in layout_arg_by_refRichard Henderson1-1/+1
Off by one error, failing to take into account that layout_arg_1 already incremented info_in_idx for the first piece. We only need care for the n-1 TCG_CALL_ARG_BY_REF_N pieces here. Cc: qemu-stable@nongnu.org Fixes: 313bdea84d2 ("tcg: Add TCG_CALL_{RET,ARG}_BY_REF") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1751 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit e18ed26ce785f74a17e6f3a095647e08ba6fc669) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user/syscall: Implement execve without execveatPierrick Bouvier1-8/+12
Support for execveat syscall was implemented in 55bbe4 and is available since QEMU 8.0.0. It relies on host execveat, which is widely available on most of Linux kernels today. However, this change breaks qemu-user self emulation, if "host" qemu version is less than 8.0.0. Indeed, it does not implement yet execveat. This strange use case happens with most of distribution today having binfmt support. With a concrete failing example: $ qemu-x86_64-7.2 qemu-x86_64-8.0 /bin/bash -c /bin/ls /bin/bash: line 1: /bin/ls: Function not implemented -> not implemented means execve returned ENOSYS qemu-user-static 7.2 and 8.0 can be conveniently grabbed from debian packages qemu-user-static* [1]. One usage of this is running wine-arm64 from linux-x64 (details [2]). This is by updating qemu embedded in docker image that we ran into this issue. The solution to update host qemu is not always possible. Either it's complicated or ask you to recompile it, or simply is not accessible (GitLab CI, GitHub Actions). Thus, it could be worth to implement execve without relying on execveat, which is the goal of this patch. This patch was tested with example presented in this commit message. [1] http://ftp.us.debian.org/debian/pool/main/q/qemu/ [1] https://www.linaro.org/blog/emulate-windows-on-arm/ Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <20230705121023.973284-1-pierrick.bouvier@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 7a8d9f3a0e882df50681e40f09c29cfb4966ea2d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31hw/ide/piix: properly initialize the BMIBA registerOlaf Hering1-1/+1
According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS MASTER INTERFACE BASE ADDRESS REGISTER, April 1997), the register is 32bit wide. To properly reset it to default values, all 32bit need to be cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled. The initial change wrote just the lower 8 bit, leaving parts of the "Bus Master Interface Base Address" address at bit 15:4 unchanged. Fixes: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for 82371SB (Function 1)") Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230712074721.14728-1-olaf@aepfle.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 230dfd9257e92259876c113e58b5f0d22b056d2e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/mips: enable GINVx support for I6400 and I6500Marcin Nowakowski1-2/+2
GINVI and GINVT operations are supported on MIPS I6400 and I6500 cores, so indicate that properly in CP0.Config5 register bits [16:15]. Cc: qemu-stable@nongnu.org Signed-off-by: Marcin Nowakowski <marcin.nowakowski@fungible.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230630072806.3093704-1-marcin.nowakowski@fungible.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit baf21eebc3e1026d21d94fdf8ca470050e49968f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix LRA when DAT is offIlya Leoshkevich1-1/+1
LRA should perform DAT regardless of whether it's on or off. Disable DAT check for MMU_S390_LRA. Fixes: defb0e3157af ("s390x: Implement opcode helpers") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: qemu-stable@nongnu.org Message-Id: <20230704081506.276055-7-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit b0ef81062d2404ccef0289b1cc6e70244901c9be) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix LRA overwriting the top 32 bits on DAT errorIlya Leoshkevich3-4/+4
When a DAT error occurs, LRA is supposed to write the error information to the bottom 32 bits of R1, and leave the top 32 bits of R1 alone. Fix by passing the original value of R1 into helper and copying the top 32 bits to the return value. Fixes: d8fe4a9c284f ("target-s390: Convert LRA") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: qemu-stable@nongnu.org Message-Id: <20230704081506.276055-6-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 6da311a60d58dba27f5f790217d5ebba944e34ab) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix MVCRL with a large value in R0Ilya Leoshkevich1-0/+1
Using a large R0 causes an assertion error: qemu-s390x: target/s390x/tcg/mem_helper.c:183: access_prepare_nf: Assertion `size > 0 && size <= 4096' failed. Even though PoP explicitly advises against using more than 8 bits for the size, an emulator crash is never a good thing. Fix by truncating the size to 8 bits. Fixes: ea0a1053e276 ("s390x/tcg: Implement Miscellaneous-Instruction-Extensions Facility 3 for the s390x") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: qemu-stable@nongnu.org Message-Id: <20230704081506.276055-5-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 92a57534619a4058544ce8f9c0beae3e054f342b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix MDEB and MDEBRIlya Leoshkevich2-3/+4
These instructions multiply 32 bits by 32 bits, not 32 bits by 64 bits. Fixes: 83b00736f3d8 ("target-s390: Convert FP MULTIPLY") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: qemu-stable@nongnu.org Message-Id: <20230704081506.276055-4-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit fed9a4fe0ce0ec917a6b3a2da0a7ecd3cb9eba56) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31target/s390x: Fix EPSW CC reportingIlya Leoshkevich1-0/+4
EPSW should explicitly calculate and insert CC, like IPM does. Fixes: e30a9d3fea58 ("target-s390: Implement EPSW") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: qemu-stable@nongnu.org Message-Id: <20230704081506.276055-3-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 110b1bac2ecd94a78a1d38003e24e37367bf074e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31vfio: Fix null pointer dereference bug in vfio_bars_finalize()Avihai Horon1-1/+3
vfio_realize() has the following flow: 1. vfio_bars_prepare() -- sets VFIOBAR->size. 2. msix_early_setup(). 3. vfio_bars_register() -- allocates VFIOBAR->mr. After vfio_bars_prepare() is called msix_early_setup() can fail. If it does fail, vfio_bars_register() is never called and VFIOBAR->mr is not allocated. In this case, vfio_bars_finalize() is called as part of the error flow to free the bars' resources. However, vfio_bars_finalize() calls object_unparent() for VFIOBAR->mr after checking only VFIOBAR->size, and thus we get a null pointer dereference. Fix it by checking VFIOBAR->mr in vfio_bars_finalize(). Fixes: 89d5202edc50 ("vfio/pci: Allow relocating MSI-X MMIO") Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> (cherry picked from commit 8af87a3ec7e42ff1b9cf75ceee0451c31e34d153) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Fix accept4(SOCK_NONBLOCK) syscallHelge Deller1-1/+11
The Linux accept4() syscall allows two flags only: SOCK_NONBLOCK and SOCK_CLOEXEC, and returns -EINVAL if any other bits have been set. Change the qemu implementation accordingly, which means we can not use the fcntl_flags_tbl[] translation table which allows too many other values. Beside the correction in behaviour, this actually fixes the accept4() emulation for hppa, mips and alpha targets for which SOCK_NONBLOCK is different than TARGET_SOCK_NONBLOCK (aka O_NONBLOCK). The fix can be verified with the testcase of the debian lwt package, which hangs forever in a read() syscall without this patch. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit dca4c8384d68bbf5d67f50a5446865d92d61f032) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-31linux-user: Fix fcntl() and fcntl64() to return O_LARGEFILE for 32-bit targetsHelge Deller1-0/+4
When running a 32-bit guest on a 64-bit host, fcntl[64](F_GETFL) should return with the TARGET_O_LARGEFILE flag set, because all 64-bit hosts support large files unconditionally. But on 64-bit hosts, O_LARGEFILE has the value 0, so the flag translation can't be done with the fcntl_flags_tbl[]. Instead add the TARGET_O_LARGEFILE flag afterwards. Note that for 64-bit guests the compiler will optimize away this code, since TARGET_O_LARGEFILE is zero. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e0ddf8eac9f83c0bc5a3d39605d873ee0fe53421) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-17hw/ppc: Fix clock update driftNicholas Piggin1-16/+17
The clock update logic reads the clock twice to compute the new clock value, with a value derived from the later time subtracted from a value derived from the earlier time. The delta causes time to be lost. This can ultimately result in time becoming unsynchronized between CPUs and that can cause OS lockups, timeouts, watchdogs, etc. This can be seen running a KVM guest (that causes lots of TB updates) on a powernv SMP machine. Fix this by reading the clock once. Cc: qemu-stable@nongnu.org Fixes: dbdd25065e90 ("Implement time-base start/stop helpers.") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230629020713.327745-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 2ad2e113deb5663e69a05dd6922cbfc6d7ea34d3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-09qemu_cleanup: begin drained section after vm_shutdown()Fiona Ebner1-7/+7
in order to avoid requests being stuck in a BlockBackend's request queue during cleanup. Having such requests can lead to a deadlock [0] with a virtio-scsi-pci device using iothread that's busy with IO when initiating a shutdown with QMP 'quit'. There is a race where such a queued request can continue sometime (maybe after bdrv_child_free()?) during bdrv_root_unref_child() [1]. The completion will hold the AioContext lock and wait for the BQL during SCSI completion, but the main thread will hold the BQL and wait for the AioContext as part of bdrv_root_unref_child(), leading to the deadlock [0]. [0]: > Thread 3 (Thread 0x7f3bbd87b700 (LWP 135952) "qemu-system-x86"): > #0 __lll_lock_wait (futex=futex@entry=0x564183365f00 <qemu_global_mutex>, private=0) at lowlevellock.c:52 > #1 0x00007f3bc1c0d843 in __GI___pthread_mutex_lock (mutex=0x564183365f00 <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80 > #2 0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x564183365f00 <qemu_global_mutex>, file=0x564182b7f774 "../softmmu/physmem.c", line=2593) at ../util/qemu-thread-posix.c:94 > #3 0x000056418247cc2a in qemu_mutex_lock_iothread_impl (file=0x564182b7f774 "../softmmu/physmem.c", line=2593) at ../softmmu/cpus.c:504 > #4 0x00005641826d5325 in prepare_mmio_access (mr=0x5641856148a0) at ../softmmu/physmem.c:2593 > #5 0x00005641826d6fe7 in address_space_stl_internal (as=0x56418679b310, addr=4276113408, val=16418, attrs=..., result=0x0, endian=DEVICE_LITTLE_ENDIAN) at /home/febner/repos/qemu/memory_ldst.c.inc:318 > #6 0x00005641826d7154 in address_space_stl_le (as=0x56418679b310, addr=4276113408, val=16418, attrs=..., result=0x0) at /home/febner/repos/qemu/memory_ldst.c.inc:357 > #7 0x0000564182374b07 in pci_msi_trigger (dev=0x56418679b0d0, msg=...) at ../hw/pci/pci.c:359 > #8 0x000056418237118b in msi_send_message (dev=0x56418679b0d0, msg=...) at ../hw/pci/msi.c:379 > #9 0x0000564182372c10 in msix_notify (dev=0x56418679b0d0, vector=8) at ../hw/pci/msix.c:542 > #10 0x000056418243719c in virtio_pci_notify (d=0x56418679b0d0, vector=8) at ../hw/virtio/virtio-pci.c:77 > #11 0x00005641826933b0 in virtio_notify_vector (vdev=0x5641867a34a0, vector=8) at ../hw/virtio/virtio.c:1985 > #12 0x00005641826948d6 in virtio_irq (vq=0x5641867ac078) at ../hw/virtio/virtio.c:2461 > #13 0x0000564182694978 in virtio_notify (vdev=0x5641867a34a0, vq=0x5641867ac078) at ../hw/virtio/virtio.c:2473 > #14 0x0000564182665b83 in virtio_scsi_complete_req (req=0x7f3bb000e5d0) at ../hw/scsi/virtio-scsi.c:115 > #15 0x00005641826670ce in virtio_scsi_complete_cmd_req (req=0x7f3bb000e5d0) at ../hw/scsi/virtio-scsi.c:641 > #16 0x000056418266736b in virtio_scsi_command_complete (r=0x7f3bb0010560, resid=0) at ../hw/scsi/virtio-scsi.c:712 > #17 0x000056418239aac6 in scsi_req_complete (req=0x7f3bb0010560, status=2) at ../hw/scsi/scsi-bus.c:1526 > #18 0x000056418239e090 in scsi_handle_rw_error (r=0x7f3bb0010560, ret=-123, acct_failed=false) at ../hw/scsi/scsi-disk.c:242 > #19 0x000056418239e13f in scsi_disk_req_check_error (r=0x7f3bb0010560, ret=-123, acct_failed=false) at ../hw/scsi/scsi-disk.c:265 > #20 0x000056418239e482 in scsi_dma_complete_noio (r=0x7f3bb0010560, ret=-123) at ../hw/scsi/scsi-disk.c:340 > #21 0x000056418239e5d9 in scsi_dma_complete (opaque=0x7f3bb0010560, ret=-123) at ../hw/scsi/scsi-disk.c:371 > #22 0x00005641824809ad in dma_complete (dbs=0x7f3bb000d9d0, ret=-123) at ../softmmu/dma-helpers.c:107 > #23 0x0000564182480a72 in dma_blk_cb (opaque=0x7f3bb000d9d0, ret=-123) at ../softmmu/dma-helpers.c:127 > #24 0x00005641827bf78a in blk_aio_complete (acb=0x7f3bb00021a0) at ../block/block-backend.c:1563 > #25 0x00005641827bfa5e in blk_aio_write_entry (opaque=0x7f3bb00021a0) at ../block/block-backend.c:1630 > #26 0x000056418295638a in coroutine_trampoline (i0=-1342102448, i1=32571) at ../util/coroutine-ucontext.c:177 > #27 0x00007f3bc0caed40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #28 0x00007f3bbd8757f0 in ?? () > #29 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7f3bbe3e9280 (LWP 135944) "qemu-system-x86"): > #0 __lll_lock_wait (futex=futex@entry=0x5641856f2a00, private=0) at lowlevellock.c:52 > #1 0x00007f3bc1c0d8d1 in __GI___pthread_mutex_lock (mutex=0x5641856f2a00) at ../nptl/pthread_mutex_lock.c:115 > #2 0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x5641856f2a00, file=0x564182c0e319 "../util/async.c", line=728) at ../util/qemu-thread-posix.c:94 > #3 0x000056418293a140 in qemu_rec_mutex_lock_impl (mutex=0x5641856f2a00, file=0x564182c0e319 "../util/async.c", line=728) at ../util/qemu-thread-posix.c:149 > #4 0x00005641829532d5 in aio_context_acquire (ctx=0x5641856f29a0) at ../util/async.c:728 > #5 0x000056418279d5df in bdrv_set_aio_context_commit (opaque=0x5641856e6e50) at ../block.c:7493 > #6 0x000056418294e288 in tran_commit (tran=0x56418630bfe0) at ../util/transactions.c:87 > #7 0x000056418279d880 in bdrv_try_change_aio_context (bs=0x5641856f7130, ctx=0x56418548f810, ignore_child=0x0, errp=0x0) at ../block.c:7626 > #8 0x0000564182793f39 in bdrv_root_unref_child (child=0x5641856f47d0) at ../block.c:3242 > #9 0x00005641827be137 in blk_remove_bs (blk=0x564185709880) at ../block/block-backend.c:914 > #10 0x00005641827bd689 in blk_remove_all_bs () at ../block/block-backend.c:583 > #11 0x0000564182798699 in bdrv_close_all () at ../block.c:5117 > #12 0x000056418248a5b2 in qemu_cleanup () at ../softmmu/runstate.c:821 > #13 0x0000564182738603 in qemu_default_main () at ../softmmu/main.c:38 > #14 0x0000564182738631 in main (argc=30, argv=0x7ffd675a8a48) at ../softmmu/main.c:48 > > (gdb) p *((QemuMutex*)0x5641856f2a00) > $1 = {lock = {__data = {__lock = 2, __count = 2, __owner = 135952, ... > (gdb) p *((QemuMutex*)0x564183365f00) > $2 = {lock = {__data = {__lock = 2, __count = 0, __owner = 135944, ... [1]: > Thread 1 "qemu-system-x86" hit Breakpoint 5, bdrv_drain_all_end () at ../block/io.c:551 > #0 bdrv_drain_all_end () at ../block/io.c:551 > #1 0x00005569810f0376 in bdrv_graph_wrlock (bs=0x0) at ../block/graph-lock.c:156 > #2 0x00005569810bd3e0 in bdrv_replace_child_noperm (child=0x556982e2d7d0, new_bs=0x0) at ../block.c:2897 > #3 0x00005569810bdef2 in bdrv_root_unref_child (child=0x556982e2d7d0) at ../block.c:3227 > #4 0x00005569810e8137 in blk_remove_bs (blk=0x556982e42880) at ../block/block-backend.c:914 > #5 0x00005569810e7689 in blk_remove_all_bs () at ../block/block-backend.c:583 > #6 0x00005569810c2699 in bdrv_close_all () at ../block.c:5117 > #7 0x0000556980db45b2 in qemu_cleanup () at ../softmmu/runstate.c:821 > #8 0x0000556981062603 in qemu_default_main () at ../softmmu/main.c:38 > #9 0x0000556981062631 in main (argc=30, argv=0x7ffd7a82a418) at ../softmmu/main.c:48 > [Switching to Thread 0x7fe76dab2700 (LWP 103649)] > > Thread 3 "qemu-system-x86" hit Breakpoint 4, blk_inc_in_flight (blk=0x556982e42880) at ../block/block-backend.c:1505 > #0 blk_inc_in_flight (blk=0x556982e42880) at ../block/block-backend.c:1505 > #1 0x00005569810e8f36 in blk_wait_while_drained (blk=0x556982e42880) at ../block/block-backend.c:1312 > #2 0x00005569810e9231 in blk_co_do_pwritev_part (blk=0x556982e42880, offset=3422961664, bytes=4096, qiov=0x556983028060, qiov_offset=0, flags=0) at ../block/block-backend.c:1402 > #3 0x00005569810e9a4b in blk_aio_write_entry (opaque=0x556982e2cfa0) at ../block/block-backend.c:1628 > #4 0x000055698128038a in coroutine_trampoline (i0=-2090057872, i1=21865) at ../util/coroutine-ucontext.c:177 > #5 0x00007fe770f50d40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x00007ffd7a829570 in ?? () > #7 0x0000000000000000 in ?? () Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20230706131418.423713-1-f.ebner@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ca2a5e630dc1f569266fb663bf0b65e4eb433fb2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-09virtio-net: correctly report maximum tx_queue_size valueLaurent Vivier1-2/+2
Maximum value for tx_queue_size depends on the backend type. 1024 for vDPA/vhost-user, 256 for all the others. The value is returned by virtio_net_max_tx_queue_size() to set the parameter: n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n), n->net_conf.tx_queue_size); But the parameter checking uses VIRTQUEUE_MAX_SIZE (1024). So the parameter is silently ignored and ethtool reports a different value than the one provided by the user. ... -netdev tap,... -device virtio-net,tx_queue_size=1024 # ethtool -g enp0s2 Ring parameters for enp0s2: Pre-set maximums: RX: 256 RX Mini: n/a RX Jumbo: n/a TX: 256 Current hardware settings: RX: 256 RX Mini: n/a RX Jumbo: n/a TX: 256 ... -netdev vhost-user,... -device virtio-net,tx_queue_size=2048 Invalid tx_queue_size (= 2048), must be a power of 2 between 256 and 1024 With this patch the correct maximum value is checked and displayed. For vDPA/vhost-user: Invalid tx_queue_size (= 2048), must be a power of 2 between 256 and 1024 For all the others: Invalid tx_queue_size (= 512), must be a power of 2 between 256 and 256 Fixes: 2eef278b9e63 ("virtio-net: fix tx queue size for !vhost-user") Cc: mst@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 4271f4038372f174dbafffacca1a748d058a03ba) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-09Update version for 8.0.3 releasev8.0.3Michael Tokarev1-1/+1
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-08target/arm: Fix SME full tile indexingRichard Henderson3-7/+107
For the outer product set of insns, which take an entire matrix tile as output, the argument is not a combined tile+column. Therefore using get_tile_rowcol was incorrect, as we extracted the tile number from itself. The test case relies only on assembler support for SME, since no release of GCC recognizes -march=armv9-a+sme yet. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1620 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230622151201.1578522-5-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: dropped now-unneeded changes to sysregs CFLAGS] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 1f51573f7925b80e79a29f87c7d9d6ead60960c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup context in tests/tcg/aarch64/Makefile.target)
2023-07-02accel/tcg: Assert one page in tb_invalidate_phys_page_range__lockedMark Cave-Ayland1-0/+3
Ensure that that both the start and last addresses are within the same guest page. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230629082522.606219-3-mark.cave-ayland@ilande.co.uk> [rth: Use tcg_debug_assert, simplify the expression] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit e665cf72fe6357945fdbecf747dac58c0c7c7c66) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-02accel/tcg: Fix start page passed to tb_invalidate_phys_page_range__lockedMark Cave-Ayland1-4/+6
Due to a copy-paste error in tb_invalidate_phys_range, the wrong start address was passed to tb_invalidate_phys_page_range__locked. Correct is to use the start of each page in turn. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: e506ad6a05 ("accel/tcg: Pass last not end to tb_invalidate_phys_range") Message-Id: <20230629082522.606219-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 3307e08c6f142bb3d2406cfbc0ee19359748b51a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-02ui/gtk: set the area of the scanout texture correctlyDongwon Kim2-2/+4
x and y offsets and width and height of the scanout texture is not correctly configured in case guest scanout frame is dmabuf. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Message-ID: <20230621213150.29573-1-dongwon.kim@intel.com> (cherry picked from commit 37802a24eb4e535d96d6fe0273505d2b5c6528c2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-01linux-user: Avoid mmap of the last byte of the reserved_vaRichard Henderson1-4/+10
There is an overflow problem in mmap_find_vma_reserved: when reserved_va == UINT32_MAX, end may overflow to 0. Rather than a larger rewrite at this time, simply avoid the final byte of the VA, which avoids searching the final page, which avoids the overflow. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1741 Fixes: 95059f9c ("include/exec: Change reserved_va semantics to last byte") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <20230629080835.71371-1-richard.henderson@linaro.org> (cherry picked from commit 605a8b5491a119a2a6efbf61e5a38f9374645990) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-06-30vfio/pci: Call vfio_prepare_kvm_msi_virq_batch() in MSI retry pathShameer Kolothum1-2/+2
When vfio_enable_vectors() returns with less than requested nr_vectors we retry with what kernel reported back. But the retry path doesn't call vfio_prepare_kvm_msi_virq_batch() and this results in, qemu-system-aarch64: vfio: Error: Failed to enable 4 MSI vectors, retry with 1 qemu-system-aarch64: ../hw/vfio/pci.c:602: vfio_commit_kvm_msi_virq_batch: Assertion `vdev->defer_kvm_irq_routing' failed Fixes: dc580d51f7dd ("vfio: defer to commit kvm irq routing when enable msi/msix") Reviewed-by: Longpeng <longpeng2@huawei.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Cédric Le Goater <clg@redhat.com> (cherry picked from commit c17408892319712c12357e5d1c6b305499c58c2a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>