qemu/qemu.git, branch stable-8.1

Update version for 8.1.5 release

2024-01-29T11:20:00+00:00

Signed-off-by: Michael Tokarev

target/arm: Fix A64 scalar SQSHRN and SQRSHRN

2024-01-27T15:10:41+00:00

In commit 1b7bc9b5c8bf374dd we changed handle_vec_simd_sqshrn() so that instead of starting with a 0 value and depositing in each new element from the narrowing operation, it instead started with the raw result of the narrowing operation of the first element. This is fine in the vector case, because the deposit operations for the second and subsequent elements will always overwrite any higher bits that might have been in the first element's result value in tcg_rd. However in the scalar case we only go through this loop once. The effect is that for a signed narrowing operation, if the result is negative then we will now return a value where the bits above the first element are incorrectly 1 (because the narrowfn returns a sign-extended result, not one that is truncated to the element size). Fix this by using an extract operation to get exactly the correct bits of the output of the narrowfn for element 1, instead of a plain move. Cc: qemu-stable@nongnu.org Fixes: 1b7bc9b5c8bf374dd3 ("target/arm: Avoid tcg_const_ptr in handle_vec_simd_sqshrn") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089 Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-id: 20240123153416.877308-1-peter.maydell@linaro.org (cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a) Signed-off-by: Michael Tokarev

target/xtensa: fix OOB TLB entry access

2024-01-27T15:05:25+00:00

r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register by the guest. The host uses 3 bits of the index for ITLB indexing and 4 bits for DTLB, but there's only 7 entries in the ITLB array and 10 in the DTLB array, so a malicious guest may trigger out-of-bound access to these arrays. Change split_tlb_entry_spec return type to bool to indicate whether TLB way passed to it is valid. Change get_tlb_entry to return NULL in case invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that requested TLB way and entry indices are valid. Add checks to the [rwi]tlb helpers that requested TLB way is valid and return 0 or do nothing when it's not. Cc: qemu-stable@nongnu.org Fixes: b67ea0cd7441 ("target-xtensa: implement memory protection options") Signed-off-by: Max Filippov Reviewed-by: Peter Maydell Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com Signed-off-by: Peter Maydell (cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32) Signed-off-by: Michael Tokarev

qtest: bump aspeed_smc-test timeout to 6 minutes

2024-01-26T16:54:36+00:00

On a loaded system with --enable-debug, this test can take longer than 5 minutes. Raising the timeout to 6 minutes gives greater headroom for such situations. Signed-off-by: Daniel P. Berrangé [thuth: Increase the timeout to 6 minutes for very loaded systems] Signed-off-by: Thomas Huth Message-Id: <20231215070357.10888-11-thuth@redhat.com> Signed-off-by: Alex Bennée (cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29) Signed-off-by: Michael Tokarev (Mjt: context fixup in tests/qtest/meson.build)

monitor: only run coroutine commands in qemu_aio_context

2024-01-26T16:31:37+00:00

monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not polled during nested event loops. The coroutine currently reschedules itself in the main loop's qemu_aio_context AioContext, which is polled during nested event loops. One known problem is that QMP device-add calls drain_call_rcu(), which temporarily drops the BQL, leading to all sorts of havoc like other vCPU threads re-entering device emulation code while another vCPU thread is waiting in device emulation code with aio_poll(). Paolo Bonzini suggested running non-coroutine QMP handlers in the iohandler AioContext. This avoids trouble with nested event loops. His original idea was to move coroutine rescheduling to monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch() because we don't know if the QMP handler needs to run in coroutine context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have been nicer since it's associated with the monitor implementation and not as general as qmp_dispatch(), which is also used by qemu-ga. A number of qemu-iotests need updated .out files because the order of QMP events vs QMP responses has changed. Solves Issue #1933. Cc: qemu-stable@nongnu.org Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use drain_call_rcu in in qmp_device_add") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985 Buglink: https://issues.redhat.com/browse/RHEL-17369 Signed-off-by: Stefan Hajnoczi Message-ID: <20240118144823.1497953-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf Tested-by: Fiona Ebner Signed-off-by: Kevin Wolf (cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7) Signed-off-by: Michael Tokarev

iotests: port 141 to Python for reliable QMP testing

2024-01-26T16:31:37+00:00

The common.qemu bash functions allow tests to interact with the QMP monitor of a QEMU process. I spent two days trying to update 141 when the order of the test output changed, but found it would still fail occassionally because printf() and QMP events race with synchronous QMP communication. I gave up and ported 141 to the existing Python API for QMP tests. The Python API is less affected by the order in which QEMU prints output because it does not print all QMP traffic by default. The next commit changes the order in which QMP messages are received. Make 141 reliable first. Cc: Hanna Czenczek Signed-off-by: Stefan Hajnoczi Message-ID: <20240118144823.1497953-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf (cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64) Signed-off-by: Michael Tokarev

iotests: add filter_qmp_generated_node_ids()

2024-01-26T16:31:37+00:00

Add a filter function for QMP responses that contain QEMU's automatically generated node ids. The ids change between runs and must be masked in the reference output. The next commit will use this new function. Signed-off-by: Stefan Hajnoczi Message-ID: <20240118144823.1497953-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf (cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006) Signed-off-by: Michael Tokarev

block/blklogwrites: Fix a bug when logging "write zeroes" operations.

2024-01-26T15:35:56+00:00

There is a bug in the blklogwrites driver pertaining to logging "write zeroes" operations, causing log corruption. This can be easily observed by setting detect-zeroes to something other than "off" for the driver. The issue is caused by a concurrency bug pertaining to the fact that "write zeroes" operations have to be logged in two parts: first the log entry metadata, then the zeroed-out region. While the log entry metadata is being written by bdrv_co_pwritev(), another operation may begin in the meanwhile and modify the state of the blklogwrites driver. This is as intended by the coroutine-driven I/O model in QEMU, of course. Unfortunately, this specific scenario is mishandled. A short example: 1. Initially, in the current operation (#1), the current log sector number in the driver state is only incremented by the number of sectors taken by the log entry metadata, after which the log entry metadata is written. The current operation yields. 2. Another operation (#2) may start while the log entry metadata is being written. It uses the current log position as the start offset for its log entry. This is in the sector right after the operation #1 log entry metadata, which is bad! 3. After bdrv_co_pwritev() returns (#1), the current log sector number is reread from the driver state in order to find out the start offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the offset will be the sector right after the (misplaced) operation #2 log entry, which means that the zeroed-out region begins at the wrong offset. 4. As a result of the above, the log is corrupt. Fix this by only reading the driver metadata once, computing the offsets and sizes in one go (including the optional zeroed-out region) and setting the log sector number to the appropriate value for the next operation in line. Signed-off-by: Ari Sundholm Cc: qemu-stable@nongnu.org Message-ID: <20240109184646.1128475-1-megari@gmx.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf (cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6) Signed-off-by: Michael Tokarev

virtio-net: correctly copy vnet header when flushing TX

2024-01-26T13:20:04+00:00

When HASH_REPORT is negotiated, the guest_hdr_len might be larger than the size of the mergeable rx buffer header. Using virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack overflow in this case. Fixing this by using virtio_net_hdr_v1_hash instead. Reported-by: Xiao Lei Cc: Yuri Benditovich Cc: qemu-stable@nongnu.org Cc: Mauro Matteo Cascella Fixes: CVE-2023-6693 Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev Signed-off-by: Jason Wang (cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0) Signed-off-by: Michael Tokarev

tcg/arm: Fix SIGILL in tcg_out_qemu_st_direct

2024-01-25T16:14:05+00:00

When tcg_out_qemu_st_{index,direct} were merged, the direct case for MO_64 was omitted, causing qemu_st_i64 to be encoded as 0xffffffff due to underflow when adding h.base and h.index. Fixes: 1df6d611bdc2 ("tcg/arm: Introduce HostAddress") Signed-off-by: Joseph Burt Message-Id: <20240121211439.100829-1-caseorum@gmail.com> Reviewed-by: Richard Henderson Signed-off-by: Richard Henderson (cherry picked from commit 9f6523e8e4689cafdbed7c10b7cf7c775b5a607b) Signed-off-by: Michael Tokarev