[Qemu-commits] [qemu/qemu] 8ada21: hw/i2c: Fix bitbang_i2c_data trace event
Branch: refs/heads/master Home: https://github.com/qemu/qemu Commit: 8ada214a902225c90583b644cabd85bc89bf188c https://github.com/qemu/qemu/commit/8ada214a902225c90583b644cabd85bc89bf188c Author: BALATON Zoltan Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/i2c/bitbang_i2c.c M hw/i2c/trace-events Log Message: --- hw/i2c: Fix bitbang_i2c_data trace event The clock and data values were logged swapped. Correct the trace event text to match what is logged. Also fix a typo in a comment nearby. Signed-off-by: BALATON Zoltan Signed-off-by: Michael Tokarev Commit: beb1a91781f127c863740c94f865fa55a22e5c81 https://github.com/qemu/qemu/commit/beb1a91781f127c863740c94f865fa55a22e5c81 Author: Michael Tokarev Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M stubs/colo.c Log Message: --- stubs/colo.c: spelling Signed-off-by: Michael Tokarev Commit: 6ee960823da8fd780ae9912c4327b7e85e80d846 https://github.com/qemu/qemu/commit/6ee960823da8fd780ae9912c4327b7e85e80d846 Author: Luca Bonissi Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M include/exec/user/abitypes.h Log Message: --- Fixed incorrect LLONG alignment for openrisc and cris OpenRISC (or1k) has long long alignment to 4 bytes, but currently not defined in abitypes.h. This lead to incorrect packing of /epoll_event/ structure and eventually infinite loop while waiting for file descriptor[s] event[s]. Fixed also CRIS alignments (1 byte for all types). Signed-off-by: Luca Bonissi Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1770 Reviewed-by: Thomas Huth Signed-off-by: Michael Tokarev Commit: 81cd34a359a36656d2f6542226235bd318ff8873 https://github.com/qemu/qemu/commit/81cd34a359a36656d2f6542226235bd318ff8873 Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M chardev/char-socket.c Log Message: --- chardev: report the handshake error This can help to debug connection issues. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=2196182 Signed-off-by: Marc-André Lureau Reviewed-by: Daniel P. Berrangé Message-Id: <20230510072531.3937189-1-marcandre.lur...@redhat.com> Commit: 957d77863e4564454eb97f8f371096843daf4678 https://github.com/qemu/qemu/commit/957d77863e4564454eb97f8f371096843daf4678 Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/display/virtio-gpu-base.c M hw/display/virtio-gpu.c M include/hw/virtio/virtio-gpu.h Log Message: --- virtio-gpu: free BHs, by implementing unrealize Acked-by: Dongwon Kim Signed-off-by: Marc-André Lureau Message-Id: <20230726173929.690601-2-marcandre.lur...@redhat.com> Commit: a41e2d97f92b48552988b3cc62dce79d62f60dcc https://github.com/qemu/qemu/commit/a41e2d97f92b48552988b3cc62dce79d62f60dcc Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/display/virtio-gpu.c M include/hw/virtio/virtio-gpu.h Log Message: --- virtio-gpu: reset gfx resources in main thread Calling OpenGL from different threads can have bad consequences if not carefully reviewed. It's not generally supported. In my case, I was debugging a crash in glDeleteTextures from OPENGL32.DLL, where I asked qemu for gl=es, and thus ANGLE implementation was expected. libepoxy did resolution of the global pointer for glGenTexture to the GLES version from the main thread. But it resolved glDeleteTextures to the GL version, because it was done from a different thread without correct context. Oops. Let's stick to the main thread for GL calls by using a BH. Note: I didn't use atomics for reset_finished check, assuming the BQL will provide enough of sync, but I might be wrong. Acked-by: Dongwon Kim Signed-off-by: Marc-André Lureau Message-Id: <20230726173929.690601-3-marcandre.lur...@redhat.com> Commit: 8a64609eea8cb2bac015968c4b62da5bce266e22 https://github.com/qemu/qemu/commit/8a64609eea8cb2bac015968c4b62da5bce266e22 Author: Dongli Zhang Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M dump/dump.c Log Message: --- dump: kdump-zlib data pages not dumped with pvtime/aarch64 The kdump-zlib data pages are not dumped from aarch64 host when the 'pvtime' is involved, that is, when the block->target_end is not aligned to page_size. In the below example, it is expected to dump two blocks. (qemu) info mtree -f ... ... 090a-090a0fff (prio 0, ram): pvtime KVM ... ... 4000-0001bfff (prio 0, ram): mach-virt.ram KVM ... ... However, there is an issue with get_next_page() so that the pages for "mach-virt.ram" will not be dumped. At line 1296, although we have reached at the end of the 'pvtime' block, since it is not aligned to the page_size (e.g., 0x1), it will not break at line 1298. 1255 static bool
[Qemu-commits] [qemu/qemu] 8ada21: hw/i2c: Fix bitbang_i2c_data trace event
Branch: refs/heads/staging Home: https://github.com/qemu/qemu Commit: 8ada214a902225c90583b644cabd85bc89bf188c https://github.com/qemu/qemu/commit/8ada214a902225c90583b644cabd85bc89bf188c Author: BALATON Zoltan Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/i2c/bitbang_i2c.c M hw/i2c/trace-events Log Message: --- hw/i2c: Fix bitbang_i2c_data trace event The clock and data values were logged swapped. Correct the trace event text to match what is logged. Also fix a typo in a comment nearby. Signed-off-by: BALATON Zoltan Signed-off-by: Michael Tokarev Commit: beb1a91781f127c863740c94f865fa55a22e5c81 https://github.com/qemu/qemu/commit/beb1a91781f127c863740c94f865fa55a22e5c81 Author: Michael Tokarev Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M stubs/colo.c Log Message: --- stubs/colo.c: spelling Signed-off-by: Michael Tokarev Commit: 6ee960823da8fd780ae9912c4327b7e85e80d846 https://github.com/qemu/qemu/commit/6ee960823da8fd780ae9912c4327b7e85e80d846 Author: Luca Bonissi Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M include/exec/user/abitypes.h Log Message: --- Fixed incorrect LLONG alignment for openrisc and cris OpenRISC (or1k) has long long alignment to 4 bytes, but currently not defined in abitypes.h. This lead to incorrect packing of /epoll_event/ structure and eventually infinite loop while waiting for file descriptor[s] event[s]. Fixed also CRIS alignments (1 byte for all types). Signed-off-by: Luca Bonissi Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1770 Reviewed-by: Thomas Huth Signed-off-by: Michael Tokarev Commit: 81cd34a359a36656d2f6542226235bd318ff8873 https://github.com/qemu/qemu/commit/81cd34a359a36656d2f6542226235bd318ff8873 Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M chardev/char-socket.c Log Message: --- chardev: report the handshake error This can help to debug connection issues. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=2196182 Signed-off-by: Marc-André Lureau Reviewed-by: Daniel P. Berrangé Message-Id: <20230510072531.3937189-1-marcandre.lur...@redhat.com> Commit: 957d77863e4564454eb97f8f371096843daf4678 https://github.com/qemu/qemu/commit/957d77863e4564454eb97f8f371096843daf4678 Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/display/virtio-gpu-base.c M hw/display/virtio-gpu.c M include/hw/virtio/virtio-gpu.h Log Message: --- virtio-gpu: free BHs, by implementing unrealize Acked-by: Dongwon Kim Signed-off-by: Marc-André Lureau Message-Id: <20230726173929.690601-2-marcandre.lur...@redhat.com> Commit: a41e2d97f92b48552988b3cc62dce79d62f60dcc https://github.com/qemu/qemu/commit/a41e2d97f92b48552988b3cc62dce79d62f60dcc Author: Marc-André Lureau Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M hw/display/virtio-gpu.c M include/hw/virtio/virtio-gpu.h Log Message: --- virtio-gpu: reset gfx resources in main thread Calling OpenGL from different threads can have bad consequences if not carefully reviewed. It's not generally supported. In my case, I was debugging a crash in glDeleteTextures from OPENGL32.DLL, where I asked qemu for gl=es, and thus ANGLE implementation was expected. libepoxy did resolution of the global pointer for glGenTexture to the GLES version from the main thread. But it resolved glDeleteTextures to the GL version, because it was done from a different thread without correct context. Oops. Let's stick to the main thread for GL calls by using a BH. Note: I didn't use atomics for reset_finished check, assuming the BQL will provide enough of sync, but I might be wrong. Acked-by: Dongwon Kim Signed-off-by: Marc-André Lureau Message-Id: <20230726173929.690601-3-marcandre.lur...@redhat.com> Commit: 8a64609eea8cb2bac015968c4b62da5bce266e22 https://github.com/qemu/qemu/commit/8a64609eea8cb2bac015968c4b62da5bce266e22 Author: Dongli Zhang Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M dump/dump.c Log Message: --- dump: kdump-zlib data pages not dumped with pvtime/aarch64 The kdump-zlib data pages are not dumped from aarch64 host when the 'pvtime' is involved, that is, when the block->target_end is not aligned to page_size. In the below example, it is expected to dump two blocks. (qemu) info mtree -f ... ... 090a-090a0fff (prio 0, ram): pvtime KVM ... ... 4000-0001bfff (prio 0, ram): mach-virt.ram KVM ... ... However, there is an issue with get_next_page() so that the pages for "mach-virt.ram" will not be dumped. At line 1296, although we have reached at the end of the 'pvtime' block, since it is not aligned to the page_size (e.g., 0x1), it will not break at line 1298. 1255 static bool
[Qemu-commits] [qemu/qemu] ecb1b7: hw/nvme: fix oob memory read in fdp events log
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: ecb1b7b082d3b7dceff0e486a114502fc52c0fdf
https://github.com/qemu/qemu/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf
Author: Klaus Jensen
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
---
hw/nvme: fix oob memory read in fdp events log
As reported by Trend Micro's Zero Day Initiative, an oob memory read
vulnerability exists in nvme_fdp_events(). The host-provided offset is
not verified.
Fix this.
This is only exploitable when Flexible Data Placement mode (fdp=on) is
enabled.
Fixes: CVE-2023-4135
Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
Reported-by: Trend Micro's Zero Day Initiative
Signed-off-by: Klaus Jensen
Commit: 6a33f2e920ec0b489a77200888e3692664077f2d
https://github.com/qemu/qemu/commit/6a33f2e920ec0b489a77200888e3692664077f2d
Author: Klaus Jensen
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
M hw/nvme/nvme.h
M hw/nvme/trace-events
Log Message:
---
hw/nvme: fix compliance issue wrt. iosqes/iocqes
As of prior to this patch, the controller checks the value of CC.IOCQES
and CC.IOSQES prior to enabling the controller. As reported by Ben in
GitLab issue #1691, this is not spec compliant. The controller should
only check these values when queues are created.
This patch moves these checks to nvme_create_cq(). We do not need to
check it in nvme_create_sq() since that will error out if the completion
queue is not already created.
Also, since the controller exclusively supports SQEs of size 64 bytes
and CQEs of size 16 bytes, hard code that.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1691
Signed-off-by: Klaus Jensen
Commit: e0e5dca517a5964d407f48bdfccbea88113b2736
https://github.com/qemu/qemu/commit/e0e5dca517a5964d407f48bdfccbea88113b2736
Author: Richard Henderson
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
M hw/nvme/nvme.h
M hw/nvme/trace-events
Log Message:
---
Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into
staging
hw/nvme fixes
- two fixes for hw/nvme
# -BEGIN PGP SIGNATURE-
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmTQ2y4ACgkQTeGvMW1P
# DenpWQf/WFgEljzgTcgxlfZhCyzWGwVNgKqRxlTuF6ELqm8BajCuCeA5ias6AXOr
# x/gZ0VqrL91L5tRIH5Q0sdC+HBFC1yMs66jopdzc1oL1eYu1HTrLIqMDtkXp/K/P
# PyGah2t4qEMtacSkad+hmB68ViUkkmhkxrWYIeufUQTfLNF5pBqNvB1kQON3jmXE
# a1jI/PabYxi8Km0rfFJD6SUGmL9+m7MY/SyZAy+4EZZ1OEnp5jb3o9lbdwbhIU5e
# dRX4NW4BEDiOJeIcNVDiQkXv2/Lna1B51RVMvM4owpk0eRvRXMSqs2DQ5/jp/nGb
# 8uChUJ0QW68I4e9ptTfxmBsr4pSktg==
# =0nwp
# -END PGP SIGNATURE-
# gpg: Signature made Mon 07 Aug 2023 04:53:18 AM PDT
# gpg:using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen " [unknown]
# gpg: aka "Klaus Jensen " [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838
# Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu:
hw/nvme: fix compliance issue wrt. iosqes/iocqes
hw/nvme: fix oob memory read in fdp events log
Signed-off-by: Richard Henderson
Compare: https://github.com/qemu/qemu/compare/9400601a689a...e0e5dca517a5
[Qemu-commits] [qemu/qemu] bcb1e0: virtio-net: correctly report maximum tx_queue_size...
Branch: refs/heads/stable-8.0
Home: https://github.com/qemu/qemu
Commit: bcb1e0522e77b49cf8a75c631fa8fe5b4b76202e
https://github.com/qemu/qemu/commit/bcb1e0522e77b49cf8a75c631fa8fe5b4b76202e
Author: Laurent Vivier
Date: 2023-07-09 (Sun, 09 Jul 2023)
Changed paths:
M hw/net/virtio-net.c
Log Message:
---
virtio-net: correctly report maximum tx_queue_size value
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: m...@redhat.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Laurent Vivier
Signed-off-by: Jason Wang
(cherry picked from commit 4271f4038372f174dbafffacca1a748d058a03ba)
Signed-off-by: Michael Tokarev
Commit: 720db12b8b08874fb2e83f6c039b72cad1f11b16
https://github.com/qemu/qemu/commit/720db12b8b08874fb2e83f6c039b72cad1f11b16
Author: Fiona Ebner
Date: 2023-07-09 (Sun, 09 Jul 2023)
Changed paths:
M softmmu/runstate.c
Log Message:
---
qemu_cleanup: begin drained section after vm_shutdown()
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 ,
> private=0) at lowlevellock.c:52
> #1 0x7f3bc1c0d843 in __GI___pthread_mutex_lock (mutex=0x564183365f00
> ) at ../nptl/pthread_mutex_lock.c:80
> #2 0x564182939f2e in qemu_mutex_lock_impl (mutex=0x564183365f00
> , file=0x564182b7f774 "../softmmu/physmem.c", line=2593)
> at ../util/qemu-thread-posix.c:94
> #3 0x56418247cc2a in qemu_mutex_lock_iothread_impl (file=0x564182b7f774
> "../softmmu/physmem.c", line=2593) at ../softmmu/cpus.c:504
> #4 0x5641826d5325 in prepare_mmio_access (mr=0x5641856148a0) at
> ../softmmu/physmem.c:2593
> #5 0x5641826d6fe7 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 0x5641826d7154 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 0x564182374b07 in pci_msi_trigger (dev=0x56418679b0d0, msg=...) at
> ../hw/pci/pci.c:359
> #8 0x56418237118b in msi_send_message (dev=0x56418679b0d0, msg=...) at
> ../hw/pci/msi.c:379
> #9 0x564182372c10 in msix_notify (dev=0x56418679b0d0, vector=8) at
> ../hw/pci/msix.c:542
> #10 0x56418243719c in virtio_pci_notify (d=0x56418679b0d0, vector=8) at
> ../hw/virtio/virtio-pci.c:77
> #11 0x5641826933b0 in virtio_notify_vector (vdev=0x5641867a34a0,
> vector=8) at ../hw/virtio/virtio.c:1985
> #12 0x5641826948d6 in virtio_irq (vq=0x5641867ac078) at
> ../hw/virtio/virtio.c:2461
> #13 0x564182694978 in virtio_notify (vdev=0x5641867a34a0,
> vq=0x5641867ac078) at ../hw/virtio/virtio.c:2473
> #14 0x564182665b83 in virtio_scsi_complete_req (req=0x7f3bb000e5d0) at
> ../hw/scsi/virtio-scsi.c:115
> #15 0x5641826670ce in virtio_scsi_complete_cmd_req (req=0x7f3bb000e5d0)
> at ../hw/scsi/virtio-scsi.c:641
> #16 0x56418266736b in virtio_scsi_command_complete (r=0x7f3bb0010560,
> resid=0) at
[Qemu-commits] [qemu/qemu]
Branch: refs/tags/v8.0.4 Home: https://github.com/qemu/qemu
[Qemu-commits] [qemu/qemu] ecb1b7: hw/nvme: fix oob memory read in fdp events log
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: ecb1b7b082d3b7dceff0e486a114502fc52c0fdf
https://github.com/qemu/qemu/commit/ecb1b7b082d3b7dceff0e486a114502fc52c0fdf
Author: Klaus Jensen
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
---
hw/nvme: fix oob memory read in fdp events log
As reported by Trend Micro's Zero Day Initiative, an oob memory read
vulnerability exists in nvme_fdp_events(). The host-provided offset is
not verified.
Fix this.
This is only exploitable when Flexible Data Placement mode (fdp=on) is
enabled.
Fixes: CVE-2023-4135
Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
Reported-by: Trend Micro's Zero Day Initiative
Signed-off-by: Klaus Jensen
Commit: 6a33f2e920ec0b489a77200888e3692664077f2d
https://github.com/qemu/qemu/commit/6a33f2e920ec0b489a77200888e3692664077f2d
Author: Klaus Jensen
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
M hw/nvme/nvme.h
M hw/nvme/trace-events
Log Message:
---
hw/nvme: fix compliance issue wrt. iosqes/iocqes
As of prior to this patch, the controller checks the value of CC.IOCQES
and CC.IOSQES prior to enabling the controller. As reported by Ben in
GitLab issue #1691, this is not spec compliant. The controller should
only check these values when queues are created.
This patch moves these checks to nvme_create_cq(). We do not need to
check it in nvme_create_sq() since that will error out if the completion
queue is not already created.
Also, since the controller exclusively supports SQEs of size 64 bytes
and CQEs of size 16 bytes, hard code that.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1691
Signed-off-by: Klaus Jensen
Commit: e0e5dca517a5964d407f48bdfccbea88113b2736
https://github.com/qemu/qemu/commit/e0e5dca517a5964d407f48bdfccbea88113b2736
Author: Richard Henderson
Date: 2023-08-07 (Mon, 07 Aug 2023)
Changed paths:
M hw/nvme/ctrl.c
M hw/nvme/nvme.h
M hw/nvme/trace-events
Log Message:
---
Merge tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu into
staging
hw/nvme fixes
- two fixes for hw/nvme
# -BEGIN PGP SIGNATURE-
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmTQ2y4ACgkQTeGvMW1P
# DenpWQf/WFgEljzgTcgxlfZhCyzWGwVNgKqRxlTuF6ELqm8BajCuCeA5ias6AXOr
# x/gZ0VqrL91L5tRIH5Q0sdC+HBFC1yMs66jopdzc1oL1eYu1HTrLIqMDtkXp/K/P
# PyGah2t4qEMtacSkad+hmB68ViUkkmhkxrWYIeufUQTfLNF5pBqNvB1kQON3jmXE
# a1jI/PabYxi8Km0rfFJD6SUGmL9+m7MY/SyZAy+4EZZ1OEnp5jb3o9lbdwbhIU5e
# dRX4NW4BEDiOJeIcNVDiQkXv2/Lna1B51RVMvM4owpk0eRvRXMSqs2DQ5/jp/nGb
# 8uChUJ0QW68I4e9ptTfxmBsr4pSktg==
# =0nwp
# -END PGP SIGNATURE-
# gpg: Signature made Mon 07 Aug 2023 04:53:18 AM PDT
# gpg:using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen " [unknown]
# gpg: aka "Klaus Jensen " [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838
# Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu:
hw/nvme: fix compliance issue wrt. iosqes/iocqes
hw/nvme: fix oob memory read in fdp events log
Signed-off-by: Richard Henderson
Compare: https://github.com/qemu/qemu/compare/d7ebbfc5dbda...e0e5dca517a5
[Qemu-commits] [qemu/qemu] 83a9cd: Update version for 8.0.4 release
Branch: refs/heads/staging-8.0 Home: https://github.com/qemu/qemu Commit: 83a9cdbd65ceb4a443630aed011a00ef217ed408 https://github.com/qemu/qemu/commit/83a9cdbd65ceb4a443630aed011a00ef217ed408 Author: Michael Tokarev Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M VERSION Log Message: --- Update version for 8.0.4 release Signed-off-by: Michael Tokarev
[Qemu-commits] [qemu/qemu]
Branch: refs/tags/v7.2.5 Home: https://github.com/qemu/qemu
[Qemu-commits] [qemu/qemu] 2b6a75: hw/ide/piix: properly initialize the BMIBA register
Branch: refs/heads/stable-7.2
Home: https://github.com/qemu/qemu
Commit: 2b6a75b78e5f6ec89a640a29379c749ca2651610
https://github.com/qemu/qemu/commit/2b6a75b78e5f6ec89a640a29379c749ca2651610
Author: Olaf Hering
Date: 2023-07-15 (Sat, 15 Jul 2023)
Changed paths:
M hw/ide/piix.c
Log Message:
---
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: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for
82371SB (Function 1)")
Signed-off-by: Olaf Hering
Reviewed-by: Bernhard Beschow
Reviewed-by: Philippe Mathieu-Daudé
Message-ID: <20230712074721.14728-1-o...@aepfle.de>
Signed-off-by: Paolo Bonzini
(cherry picked from commit 230dfd9257e92259876c113e58b5f0d22b056d2e)
Signed-off-by: Michael Tokarev
Commit: 8f8a8f20f48e0710d040112ad667b3297b1cd6d5
https://github.com/qemu/qemu/commit/8f8a8f20f48e0710d040112ad667b3297b1cd6d5
Author: Mauro Matteo Cascella
Date: 2023-07-18 (Tue, 18 Jul 2023)
Changed paths:
M ui/vnc-clipboard.c
Log Message:
---
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: 0bf41cab ("ui/vnc: clipboard support")
Reported-by: Kevin Denis
Signed-off-by: Mauro Matteo Cascella
Reviewed-by: Marc-André Lureau
Tested-by: Marc-André Lureau
Message-ID: <20230704084210.101822-1-mcasc...@redhat.com>
(cherry picked from commit d921fea338c1059a27ce7b75309d7a2e485f710b)
Signed-off-by: Michael Tokarev
Commit: 6e216d21b56a7545a05080a370b5ca7491fecfb3
https://github.com/qemu/qemu/commit/6e216d21b56a7545a05080a370b5ca7491fecfb3
Author: Denis V. Lunev
Date: 2023-07-25 (Tue, 25 Jul 2023)
Changed paths:
M qemu-nbd.c
Log Message:
---
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
CC: Eric Blake
CC: Vladimir Sementsov-Ogievskiy
CC:
Message-ID: <20230717145544.194786-2-...@openvz.org>
Reviewed-by: Eric Blake
Signed-off-by: Eric Blake
(cherry picked from commit 03b67621445d601c9cdc7dfe25812e9f19b81488)
Signed-off-by: Michael Tokarev
Commit: 742612345a1e6ac8b3408ee1cd1d77bc07e74180
https://github.com/qemu/qemu/commit/742612345a1e6ac8b3408ee1cd1d77bc07e74180
Author: Denis V. Lunev
Date: 2023-07-25 (Tue, 25 Jul 2023)
Changed paths:
M qemu-nbd.c
Log Message:
---
qemu-nbd: fix regression with qemu-nbd --fork run over ssh
Commit e6df58a5578fee7a50bbf36f4a50a2781cff855d
Author: Hanna Reitz
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
CC: Eric Blake
CC: Vladimir Sementsov-Ogievskiy
CC: Hanna Reitz
CC:
Message-ID: <20230717145544.194786-3-...@openvz.org>
Reviewed-by: Eric Blake
Signed-off-by: Eric Blake
(cherry picked from commit 5c56dd27a2c905c9cf2472d2fd057621ce5fd00d)
Signed-off-by: Michael Tokarev
Commit: 3b80317c91b66b52b855b380d2d996701becfbde
https://github.com/qemu/qemu/commit/3b80317c91b66b52b855b380d2d996701becfbde
Author: Denis V. Lunev
Date: 2023-07-31 (Mon, 31 Jul 2023)
Changed paths:
M qemu-nbd.c
Log Message:
---
qemu-nbd: regression with arguments passing into nbd_client_thread()
Unfortunately
commit 03b67621445d601c9cdc7dfe25812e9f19b81488
(7.2: 6e216d21b56a7545a05080a370b5ca7491fecfb3)
Author: Denis V. Lunev
Date: Mon
[Qemu-commits] [qemu/qemu] 9abcf9: Update version for 7.2.5 release
Branch: refs/heads/staging-7.2 Home: https://github.com/qemu/qemu Commit: 9abcf9776d8906c53feacab686f3d50137654b62 https://github.com/qemu/qemu/commit/9abcf9776d8906c53feacab686f3d50137654b62 Author: Michael Tokarev Date: 2023-08-07 (Mon, 07 Aug 2023) Changed paths: M VERSION Log Message: --- Update version for 7.2.5 release Signed-off-by: Michael Tokarev
