Comparing changes
Open a pull request
base repository: qemu/qemu
base: 681858ea1424
head repository: qemu/qemu
compare: a543b30740f6
- 13 commits
- 17 files changed
- 6 contributors
Commits on Jul 15, 2023
-
hw/ide/piix: properly initialize the BMIBA register
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: e6a71ae ("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 230dfd9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commits on Jul 18, 2023
-
ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)
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: 0bf41ca ("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 d921fea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Mauro Matteo Cascella authored and Michael Tokarev committedJul 18, 2023
Commits on Jul 25, 2023
-
qemu-nbd: pass structure into nbd_client_thread instead of plain char*
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 03b6762) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis V. Lunev authored and Michael Tokarev committedJul 25, 2023 -
qemu-nbd: fix regression with qemu-nbd --fork run over ssh
Commit e6df58a 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 0eaf453, also fixing up e6df58a. 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 5c56dd2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis V. Lunev authored and Michael Tokarev committedJul 25, 2023 -
target/s390x: Make CKSM raise an exception if R2 is odd
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: e023e83 ("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 761b0aa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
target/s390x: Fix CLM with M3=0
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: defb0e3 ("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 4b6e4c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
target/s390x: Fix CONVERT TO LOGICAL/FIXED with out-of-range inputs
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: defb0e3 ("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 53684e3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
target/s390x: Fix ICM with M3=0
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: e023e83 ("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 a202555) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
target/s390x: Make MC raise specification exception when class >= 16
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: 20d143e ("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 9c028c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context edit in target/s390x/tcg/translate.c)
-
target/s390x: Fix assertion failure in VFMIN/VFMAX with type 13
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: da48075 ("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 ff537b0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
target/loongarch: Fix the CSRRD CPUID instruction on big endian hosts
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 c34ad45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
vhost: register and change IOMMU flag depending on Device-TLB state
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 ee071f6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
-
virtio-net: pass Device-TLB enable/disable events to vhost
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 cd9b834) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 681858ea1424...a543b30740f6