https://github.com/qemu/qemu

sort by:
Revision Author Date Message Commit Date
20a1b34 Update version for 8.1.5 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 January 2024, 11:20:00 UTC
ccdb4cc target/arm: Fix A64 scalar SQSHRN and SQRSHRN 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 <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240123153416.877308-1-peter.maydell@linaro.org (cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 January 2024, 15:10:41 UTC
b86fa3a target/xtensa: fix OOB TLB entry access 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 <jcmvbkbc@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 27 January 2024, 15:05:25 UTC
d24dd10 qtest: bump aspeed_smc-test timeout to 6 minutes 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é <berrange@redhat.com> [thuth: Increase the timeout to 6 minutes for very loaded systems] Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20231215070357.10888-11-thuth@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> (cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup in tests/qtest/meson.build) 26 January 2024, 16:54:36 UTC
4b02c71 monitor: only run coroutine commands in qemu_aio_context 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 <stefanha@redhat.com> Message-ID: <20240118144823.1497953-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 26 January 2024, 16:31:37 UTC
2f5e27e iotests: port 141 to Python for reliable QMP testing 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 <hreitz@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20240118144823.1497953-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 26 January 2024, 16:31:37 UTC
03bc938 iotests: add filter_qmp_generated_node_ids() 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 <stefanha@redhat.com> Message-ID: <20240118144823.1497953-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 26 January 2024, 16:31:37 UTC
23a512f block/blklogwrites: Fix a bug when logging "write zeroes" operations. 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 <ari@tuxera.com> Cc: qemu-stable@nongnu.org Message-ID: <20240109184646.1128475-1-megari@gmx.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 26 January 2024, 15:35:56 UTC
dd1d3c8 virtio-net: correctly copy vnet header when flushing TX 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 <leixiao.nop@zju.edu.cn> Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: qemu-stable@nongnu.org Cc: Mauro Matteo Cascella <mcascell@redhat.com> Fixes: CVE-2023-6693 Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report") Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 26 January 2024, 13:20:04 UTC
c173670 tcg/arm: Fix SIGILL in tcg_out_qemu_st_direct 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 <caseorum@gmail.com> Message-Id: <20240121211439.100829-1-caseorum@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 9f6523e8e4689cafdbed7c10b7cf7c775b5a607b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 25 January 2024, 16:14:05 UTC
76a9da3 block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_status Using fleecing backup like in [0] on a qcow2 image (with metadata preallocation) can lead to the following assertion failure: > bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed. In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag will be set by the qcow2 driver, so the caller will recursively check the file child. Then the BDRV_BLOCK_ZERO set too. Later up the call chain, in bdrv_co_do_block_status() for the snapshot-access driver, the assertion failure will happen, because both flags are set. To fix it, clear the recurse flag after the recursive check was done. In detail: > #0 qcow2_co_block_status Returns 0x45 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID. > #1 bdrv_co_do_block_status Because of the data flag, bdrv_co_do_block_status() will now also set BDRV_BLOCK_ALLOCATED. Because of the recurse flag, bdrv_co_do_block_status() for the bdrv_file child will be called, which returns 0x16 = BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ZERO. Now the return value inherits the zero flag. Returns 0x57 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_ZERO. > #2 bdrv_co_common_block_status_above > #3 bdrv_co_block_status_above > #4 bdrv_co_block_status > #5 cbw_co_snapshot_block_status > #6 bdrv_co_snapshot_block_status > #7 snapshot_access_co_block_status > #8 bdrv_co_do_block_status Return value is propagated all the way up to here, where the assertion failure happens, because BDRV_BLOCK_RECURSE and BDRV_BLOCK_ZERO are both set. > #9 bdrv_co_common_block_status_above > #10 bdrv_co_block_status_above > #11 block_copy_block_status > #12 block_copy_dirty_clusters > #13 block_copy_common > #14 block_copy_async_co_entry > #15 coroutine_trampoline [0]: > #!/bin/bash > rm /tmp/disk.qcow2 > ./qemu-img create /tmp/disk.qcow2 -o preallocation=metadata -f qcow2 1G > ./qemu-img create /tmp/fleecing.qcow2 -f qcow2 1G > ./qemu-img create /tmp/backup.qcow2 -f qcow2 1G > ./qemu-system-x86_64 --qmp stdio \ > --blockdev qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 \ > --blockdev qcow2,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.qcow2 \ > --blockdev qcow2,node-name=node2,file.driver=file,file.filename=/tmp/backup.qcow2 \ > <<EOF > {"execute": "qmp_capabilities"} > {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write", "file": "node0", "target": "node1", "node-name": "node3" } } > {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", "file": "node3", "node-name": "snap0" } } > {"execute": "blockdev-backup", "arguments": { "device": "snap0", "target": "node1", "sync": "full", "job-id": "backup0" } } > EOF Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Message-id: 20240116154839.401030-1-f.ebner@proxmox.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 8a9be7992426c8920d4178e7dca59306a18c7a3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 25 January 2024, 16:14:05 UTC
4b06bb5 accel/tcg: Revert mapping of PCREL translation block to multiple virtual addresses This is causing regressions that have not been analyzed yet. Revert the change on stable branches. Cc: qemu-stable@nongnu.org Cc: Michael Tokarev <mjt@tls.msk.ru> Related: https://gitlab.com/qemu-project/qemu/-/issues/2092 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 25 January 2024, 16:14:05 UTC
25ff741 readthodocs: fully specify a build environment This is now expected by rtd so I've expanded using their example as 22.04 is one of our supported platforms. I tried to work out if there was an easy way to re-generate a requirements.txt from our pythondeps.toml but in the end went for the easier solution. Cc: <qemu-stable@nongnu.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231221174200.2693694-1-alex.bennee@linaro.org> (cherry picked from commit b16a45bc5e0e329a16af8a2e020a6e7044f9afa2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 23 January 2024, 15:48:41 UTC
72694a6 hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issued Even though the BLAST command isn't fully implemented in QEMU, the DMA_STAT_BCMBLT bit should be set after the command has been issued to indicate that the command has completed. This fixes an issue with the DC390 DOS driver which issues the BLAST command as part of its normal error recovery routine at startup, and otherwise sits in a tight loop waiting for DMA_STAT_BCMBLT to be set before continuing. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 15:25:50 UTC
01db312 hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion interrupt The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to generate an interrupt, however the Linux driver manually checks for DMA_STAT_DONE being set and if it is, considers that a DMA transfer has completed. If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then the Linux driver considers this to be a spurious interrupt. However this can occur in QEMU as there is a delay between the end of DMA transfer where DMA_STAT_DONE is set, and the ESP device raising its completion interrupt. This appears to be an incorrect assumption in the Linux driver as the ESP and PCI DMA interrupt sources are separate (and may not be raised exactly together), however we can work around this by synchronising the setting of DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt. In conjunction with the previous commit Linux is now able to correctly boot from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting "iget: checksum invalid" and "Spurious irq, sreg=10" errors. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 15:25:50 UTC
e8cb126 hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sources The am53c974/dc390 PCI interrupt has two separate sources: the first is from the internal ESP device, and the second is from the PCI DMA transfer logic. Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function to generate the correct PCI IRQ level. In particular this fixes spurious interrupts being generated by setting DMA_STAT_DONE at the end of a transfer if DMA_CMD_INTE_D isn't set in the DMA_CMD register. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 15:25:50 UTC
2cd67d0 hw/scsi/esp-pci: use correct address register for PCI DMA transfers The current code in esp_pci_dma_memory_rw() sets the DMA address to the value of the DMA_SPA (Starting Physical Address) register which is incorrect: this means that for each callback from the SCSI layer the DMA address is set back to the starting address. In the case where only a single SCSI callback occurs (currently for transfer lengths < 128kB) this works fine, however for larger transfers the DMA address wraps back to the initial starting address, corrupting the buffer holding the data transferred to the guest. Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for the DMA address which is correctly incremented across multiple SCSI layer transfers. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 15:25:50 UTC
2472f84 migration/rdma: define htonll/ntohll only if not predefined Solaris has #defines for htonll and ntohll which cause syntax errors when compiling code that attempts to (re)define these functions.. Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com> Link: https://lore.kernel.org/r/65a04a7d.497ab3.3e7bef1f@gateway.sonic.net Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 44ce1b5d2fc77343f6a318cb3de613336a240048) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 14:57:17 UTC
fcc79f2 hw/pflash: implement update buffer for block writes Add an update buffer where all block updates are staged. Flush or discard updates properly, so we should never see half-completed block writes in pflash storage. Drop a bunch of FIXME comments ;) Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-4-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop const in hw/block/pflash_cfi01.c for before v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState") 20 January 2024, 10:44:00 UTC
dd25df3 hw/pflash: use ldn_{be,le}_p and stn_{be,le}_p Use the helper functions we have to read/write multi-byte values in correct byte order. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-3-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 10:29:58 UTC
d83b0f6 hw/pflash: refactor pflash_data_write() Move the offset calculation, do it once at the start of the function and let the 'p' variable point directly to the memory location which should be updated. This makes it simpler to update other buffers than pfl->storage in an upcoming patch. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240108160900.104835-2-kraxel@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 10:29:58 UTC
a898897 backends/cryptodev: Do not ignore throttle/backends Errors Both cryptodev_backend_set_throttle() and CryptoDevBackendClass::init() can set their Error** argument. Do not ignore them, return early on failure. Without that, running into another failure trips error_setv()'s assertion. Use the ERRP_GUARD() macro as suggested in commit ae7c80a7bd ("error: New macro ERRP_GUARD()"). Cc: qemu-stable@nongnu.org Fixes: e7a775fd9f ("cryptodev: Account statistics") Fixes: 2580b452ff ("cryptodev: support QoS") Reviewed-by: zhenwei pi <pizhenwei@bytedance.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231120150418.93443-1-philmd@linaro.org> (cherry picked from commit 484aecf2d3a75251b63481be2a0c3aef635002af) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 10:00:20 UTC
7b03b12 target/i386: pcrel: store low bits of physical address in data[0] For PC-relative translation blocks, env->eip changes during the execution of a translation block, Therefore, QEMU must be able to recover an instruction's PC just from the TranslationBlock struct and the instruction data with. Because a TB will not span two pages, QEMU stores all the low bits of EIP in the instruction data and replaces them in x86_restore_state_to_opc. Bits 12 and higher (which may vary between executions of a PCREL TB, since these only use the physical address in the hash key) are kept unmodified from env->eip. The assumption is that these bits of EIP, unlike bits 0-11, will not change as the translation block executes. Unfortunately, this is incorrect when the CS base is not aligned to a page. Then the linear address of the instructions (i.e. the one with the CS base addred) indeed will never span two pages, but bits 12+ of EIP can actually change. For example, if CS base is 0x80262200 and EIP = 0x6FF4, the first instruction in the translation block will be at linear address 0x802691F4. Even a very small TB will cross to EIP = 0x7xxx, while the linear addresses will remain comfortably within a single page. The fix is simply to use the low bits of the linear address for data[0], since those don't change. Then x86_restore_state_to_opc uses tb->cs_base to compute a temporary linear address (referring to some unknown instruction in the TB, but with the correct values of bits 12 and higher); the low bits are replaced with data[0], and EIP is obtained by subtracting again the CS base. Huge thanks to Mark Cave-Ayland for the image and initial debugging, and to Gitlab user @kjliew for help with bisecting another occurrence of (hopefully!) the same bug. It should be relatively easy to write a testcase that performs MMIO on an EIP with different bits 12+ than the first instruction of the translation block; any help is welcome. Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11) Cc: qemu-stable@nongnu.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Richard Henderson <richard.henderson@linaro.org> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 09:25:07 UTC
5707858 target/i386: fix incorrect EIP in PC-relative translation blocks The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case. Using s->pc in func gen_update_eip_next() solves the problem. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4) Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 09:24:19 UTC
99e3226 target/i386: Do not re-compute new pc with CF_PCREL With PCREL, we have a page-relative view of EIP, and an approximation of PC = EIP+CSBASE that is good enough to detect page crossings. If we try to recompute PC after masking EIP, we will mess up that approximation and write a corrupt value to EIP. We already handled masking properly for PCREL, so the fix in b5e0d5d2 was only needed for the !PCREL path. Cc: qemu-stable@nongnu.org Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation") Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4) Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 January 2024, 09:24:14 UTC
357b599 load_elf: fix iterator's type for elf file processing j is used while loading an ELF file to byteswap segments' data. If data is larger than 2GB an overflow may happen. So j should be elf_word. This commit fixes a minor bug: it's unlikely anybody is trying to load ELF files with 2GB+ segments for wrong-endianness targets, but if they did, it wouldn't work correctly. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: qemu-stable@nongnu.org Fixes: 7ef295ea5b ("loader: Add data swap option to load-elf") Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 410c2a4d75f52f6a2fe978eda5a9b6f854afe5ea) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 January 2024, 10:41:10 UTC
d6488e5 .gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large Sometimes the CI "pages" job fails with a message like this from htags: $ htags -anT --tree-view=filetree -m qemu_init -t "Welcome to the QEMU sourcecode" htags: Negative exec line limit = -371 This is due to a bug in hflags where if the environment is too large it falls over: https://lists.gnu.org/archive/html/bug-global/2024-01/msg00000.html This happens to us because GitLab CI puts the commit message of the commit under test into the CI_COMMIT_MESSAGE and/or CI_COMMIT_TAG_MESSAGE environment variables, so the job will fail if the commit happens to have a verbose commit message. Work around the htags bug by unsetting these variables while running htags. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2080 Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240111125543.1573473-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 52a21689cd829c1cc931b59b5ee5bdb10dd578c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 January 2024, 08:30:08 UTC
5e190ed target/s390x: Fix LAE setting a wrong access register LAE should set the access register corresponding to the first operand, instead, it always modifies access register 1. Co-developed-by: Ido Plat <Ido.Plat@ibm.com> Cc: qemu-stable@nongnu.org Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions") Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20240111092328.929421-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit e358a25a97c71c39e3513d9b869cdb82052e50b8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: target/s390x/tcg/translate.c: fixup for v8.1.0-1189-gad75a51e84 "tcg: Rename cpu_env to tcg_env") 13 January 2024, 08:28:25 UTC
f62b55d tests/qtest/virtio-ccw: Fix device presence checking An apparent copy-paste error tests for the presence of the virtio-rng-ccw device in order to perform tests on the virtio-scsi-ccw device. Signed-off-by: Samuel Tardieu <sam@rfc1149.net> Message-ID: <20240106130121.1244993-1-sam@rfc1149.net> Fixes: 65331bf5d1 ("tests/qtest: Check for virtio-ccw devices before using them") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit c98873ee4a0c2694aac976ab9affcf55da8b7e61) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 January 2024, 08:18:43 UTC
074b769 util: fix build with musl libc on ppc64le Use PPC_FEATURE2_ISEL and PPC_FEATURE2_VEC_CRYPTO from linux headers instead of the GNU specific PPC_FEATURE2_HAS_ISEL and PPC_FEATURE2_HAS_VEC_CRYPTO. This fixes build with musl libc. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1861 Signed-off-by: Natanael Copa <ncopa@alpinelinux.org> Fixes: 63922f467a ("tcg/ppc: Replace HAVE_ISEL macro with a variable") Fixes: 68f340d4cd ("tcg/ppc: Enable Altivec detection") Message-Id: <20231219105236.7059-1-ncopa@alpinelinux.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 1d513e06d96697f44de4a1b85c6ff627c443e306) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 11 January 2024, 18:09:30 UTC
6eb6bca hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registers The hypervisor can deliver (virtual) LPIs to a guest by setting up a list register to have an intid which is an LPI. The GIC has to treat these a little differently to standard interrupt IDs, because LPIs have no Active state, and so the guest will only EOI them, it will not also deactivate them. So icv_eoir_write() must do two things: * if the LPI ID is not in any list register, we drop the priority but do not increment the EOI count * if the LPI ID is in a list register, we immediately deactivate it, regardless of the split-drop-and-deactivate control This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1() pseudocode in the GICv3 architecture specification. Without this fix, potentially a hypervisor guest might stall because LPIs get stuck in a bogus Active+Pending state. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Miguel Luis <miguel.luis@oracle.com> (cherry picked from commit 82a65e3188abebb509510b391726711606aca642) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 11 January 2024, 17:59:38 UTC
97d3be7 chardev/char.c: fix "abstract device type" error message Current error message: qemu-system-x86_64: -chardev spice,id=foo: Parameter 'driver' expects an abstract device type while in fact the meaning is in reverse, -chardev expects a non-abstract device type. Fixes: 777357d758d9 ("chardev: qom-ify" 2016-12-07) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> (cherry picked from commit 4ad87cd4b2254197b7ac12e3da824854e6a90f8f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 08 January 2024, 16:25:17 UTC
03382b9 target/riscv: Fix mcycle/minstret increment behavior The mcycle/minstret counter's stop flag is mistakenly updated on a copy on stack. Thus the counter increments even when the CY/IR bit in the mcountinhibit register is set. This commit corrects its behavior. Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation) Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 5cb0e7abe1635cb82e0033260dac2b910d142f8c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 08 January 2024, 16:24:38 UTC
6c5dda7 hw/net/can/sja1000: fix bug for single acceptance filter and standard frame A CAN sja1000 standard frame filter mask has been computed and applied incorrectly for standard frames when single Acceptance Filter Mode (MOD_AFM = 1) has been selected. The problem has not been found by Linux kernel testing because it uses dual filter mode (MOD_AFM = 0) and leaves falters fully open. The problem has been noticed by Grant Ramsay when testing with Zephyr RTOS which uses single filter mode. Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Reported-by: Grant Ramsay <gramsay@enphaseenergy.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2028 Fixes: 733210e754 ("hw/net/can: SJA1000 chip register level emulation") Message-ID: <20240103231426.5685-1-pisa@fel.cvut.cz> (cherry picked from commit 25145a7d7735344a469551946fc2a7f19eb4aa3d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 January 2024, 19:17:14 UTC
60472f7 iotests: Basic tests for internal snapshots We have a few test cases that include tests for corner case aspects of internal snapshots, but nothing that tests that they actually function as snapshots or that involves deleting a snapshot. Add a test for this kind of basic internal snapshot functionality. The error cases include a regression test for the crash we just fixed with snapshot operations on inactive images. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231201142520.32255-4-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit bb6e2511eb48539b7dcbcb5f47772e156b9c45d1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 December 2023, 19:25:28 UTC
4c8315a vl: Improve error message for conflicting -incoming and -loadvm Currently, the conflict between -incoming and -loadvm is only detected when loading the snapshot fails because the image is still inactive for the incoming migration. This results in a suboptimal error message: $ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots Catch the situation already in qemu_validate_options() to improve the message: $ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer qemu-system-x86_64: 'incoming' and 'loadvm' options are mutually exclusive Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231201142520.32255-3-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 5a7f21efaf99c60614fe1967be1c0f9aa46c526e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 December 2023, 19:25:28 UTC
b769a8e block: Fix crash when loading snapshot on inactive node bdrv_is_read_only() only checks if the node is configured to be read-only eventually, but even if it returns false, writing to the node may not be permitted at the moment (because it's inactive). bdrv_is_writable() checks that the node can be written to right now, and this is what the snapshot operations really need. Change bdrv_can_snapshot() to use bdrv_is_writable() to fix crashes like the following: $ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer qemu-system-x86_64: ../block/io.c:1990: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, int64_t, BdrvTrackedRequest *, int): Assertion `!(bs->open_flags & BDRV_O_INACTIVE)' failed. The resulting error message after this patch isn't perfect yet, but at least it doesn't crash any more: $ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231201142520.32255-2-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit d3007d348adaaf04ee8b099a475282034a662414) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 December 2023, 19:25:28 UTC
c95e38d Update version for 8.1.4 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 December 2023, 19:10:45 UTC
c06aef0 target/arm/helper: Propagate MDCR_EL2.HPMN into PMCR_EL0.N MDCR_EL2.HPMN allows an hypervisor to limit the number of PMU counters available to EL1 and EL0 (to keep the others to itself). QEMU already implements this split correctly, except for PMCR_EL0.N reads: the number of counters read by EL1 or EL0 should be the one configured in MDCR_EL2.HPMN. Cc: qemu-stable@nongnu.org Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20231215144652.4193815-2-jean-philippe@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 6980c31dec42b6daebf7fec13b2d39ed87bb4766) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 20 December 2023, 16:07:05 UTC
5b2fd6c target/i386: Fix 32-bit wrapping of pc/eip computation In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap. Failure to do so results in incorrect memory exceptions to the guest. Before 732d548732ed, this was implicitly done via truncation to target_ulong but only in qemu-system-i386, not qemu-system-x86_64. To fix this, we must add conditional zero-extensions. Since we have to test for 32 vs 64-bit anyway, note that cs_base is always zero in 64-bit mode. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org> (cherry picked from commit b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix in target/i386/tcg/tcg-cpu.c for v8.1.0-1190-gb77af26e97 "accel/tcg: Replace CPUState.env_ptr with cpu_env()") 14 December 2023, 08:25:31 UTC
b831182 block: Fix AioContext locking in qmp_block_resize() The AioContext must be unlocked before calling blk_co_unref(), because it takes the AioContext lock internally in blk_unref_bh(), which is scheduled in the main thread. If we don't unlock, the AioContext is locked twice and nested event loops such as in bdrv_graph_wrlock() will deadlock. Cc: <qemu-stable@nongnu.org> Fixes: https://issues.redhat.com/browse/RHEL-15965 Fixes: 0c7d204f50c382c6baac8c94bd57af4a022b3888 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231208124352.30295-1-kwolf@redhat.com> (cherry picked from commit 755ae3811fec77d94e92398632cbfe23c4ecffd5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 14 December 2023, 07:11:59 UTC
fab36df system/memory: use ldn_he_p/stn_he_p Using direct pointer dereferencing can allow for unaligned accesses, which was seen during execution with sanitizers enabled. Cc: qemu-stable@nongnu.org Reviewed-by: Chris Rauer <crauer@google.com> Reviewed-by: Peter Foley <pefoley@google.com> Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20231116163633.276671-1-venture@google.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 2b8fe81b3c2e76d241510a9a85496d544e42f5ec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
25d0ca4 target/arm: Disable SME if SVE is disabled There is no architectural requirement that SME implies SVE, but our implementation currently assumes it. (FEAT_SME_FA64 does imply SVE.) So if you try to run a CPU with eg "-cpu max,sve=off" you quickly run into an assert when the guest tries to write to SMCR_EL1: #6 0x00007ffff4b38e96 in __GI___assert_fail (assertion=0x5555566e69cb "sm", file=0x5555566e5b24 "../../target/arm/helper.c", line=6865, function=0x5555566e82f0 <__PRETTY_FUNCTION__.31> "sve_vqm1_for_el_sm") at ./assert/assert.c:101 #7 0x0000555555ee33aa in sve_vqm1_for_el_sm (env=0x555557d291f0, el=2, sm=false) at ../../target/arm/helper.c:6865 #8 0x0000555555ee3407 in sve_vqm1_for_el (env=0x555557d291f0, el=2) at ../../target/arm/helper.c:6871 #9 0x0000555555ee3724 in smcr_write (env=0x555557d291f0, ri=0x555557da23b0, value=2147483663) at ../../target/arm/helper.c:6995 #10 0x0000555555fd1dba in helper_set_cp_reg64 (env=0x555557d291f0, rip=0x555557da23b0, value=2147483663) at ../../target/arm/tcg/op_helper.c:839 #11 0x00007fff60056781 in code_gen_buffer () Avoid this unsupported and slightly odd combination by disabling SME when SVE is not present. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2005 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231127173318.674758-1-peter.maydell@linaro.org (cherry picked from commit f7767ca301796334f74b9b642b395a4bd3e3dbac) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
4b26483 ui/vnc-clipboard: fix inflate_buffer Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still required, because it can happen that stream.avail_in becomes zero before coming across a return value of Z_STREAM_END in the loop. This fixes the host->guest direction of the clipboard with noVNC and TigerVNC as clients. Fixes: d921fea338 ("ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)") Reported-by: Friedrich Weber <f.weber@proxmox.com> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20231122125826.228189-1-f.ebner@proxmox.com> (cherry picked from commit ebfbf394671163c14e2b24d98f3927a3151d1aff) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
5133410 ui/gtk-egl: move function calls back to regular code path Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout") introduced a regression when QEMU is running with a virtio-gpu-gl-device on a host under X11. After the guest has initialized the virtio-gpu-gl-device, the guest screen only shows "Display output is not active.". Commit 6f189a08c1 moved all function calls in gd_egl_scanout_texture() to a code path which is only called once after gd_egl_init() succeeds in gd_egl_scanout_texture(). Move all function calls in gd_egl_scanout_texture() back to the regular code path so they get always called if one of the gd_egl_init() calls was successful. Fixes: 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout") Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20231111104020.26183-1-vr_qemu@t-online.de> (cherry picked from commit 53a939f1bf8e4a3e38f9449fac44f572676966ad) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
5a92f02 ui/gtk-egl: Check EGLSurface before doing scanout The first time gd_egl_scanout_texture() is called, there's a possibility that the GTK drawing area might not be realized yet, in which case its associated GdkWindow is NULL. This means gd_egl_init() was also skipped and the EGLContext and EGLSurface stored in the VirtualGfxConsole are not valid yet. Continuing with the scanout in this conditions would result in hitting an assert in libepoxy: "Couldn't find current GLX or EGL context". A possible workaround is to just ignore the scanout request, giving the the GTK drawing area some time to finish its realization. At that point, the gd_egl_init() will succeed and the EGLContext and EGLSurface stored in the VirtualGfxConsole will be valid. Signed-off-by: Antonio Caggiano <quic_acaggian@quicinc.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20231016123215.2699269-1-quic_acaggian@quicinc.com> (cherry picked from commit 6f189a08c1b0085808af1bfbf4567f0da193ecc1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
701afca msix: unset PCIDevice::msix_vector_poll_notifier in rollback In the rollback in msix_set_vector_notifiers(), original patch forgot to undo msix_vector_poll_notifier pointer. Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll") Signed-off-by: Robert Hoo <robert.hoo.linux@gmail.com> Message-Id: <20231113081349.1307-1-robert.hoo.linux@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2d37fe9e5e61b04bddbed00dbb7436e61a01c115) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
5c9f464 hw/acpi/erst: Do not ignore Error* in realize handler erst_realizefn() passes @errp to functions without checking for failure. If it runs into another failure, it trips error_setv()'s assertion. Use the ERRP_GUARD() macro and check *errp, as suggested in commit ae7c80a7bd ("error: New macro ERRP_GUARD()"). Cc: qemu-stable@nongnu.org Fixes: f7e26ffa59 ("ACPI ERST: support for ACPI ERST feature") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231120130017.81286-1-philmd@linaro.org> Reviewed-by: Ani Sinha <anisinha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 20bc50137f3add52eb4788b420d717de27fed14b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:51:00 UTC
ed7e167 pcie_sriov: Remove g_new assertion g_new() aborts if the allocation fails so it returns NULL only if the requested allocation size is zero. register_vfs() makes such an allocation if NumVFs is zero so it should not assert that g_new() returns a non-NULL value. Fixes: 7c0fa8dff8 ("pcie: Add support for Single Root I/O Virtualization (SR/IOV)") Buglink: https://issues.redhat.com/browse/RHEL-17209 Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231123075630.12057-1-akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Tested-by: Yanghang Liu<yanghliu@redhat.com> Reviewed-by: Cédric Le Goater <clg@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 714a1415d7a69174e1640fcdd6eaae180fe438aa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 13 December 2023, 15:50:45 UTC
59de6e2 hw/audio/hda-codec: fix multiplication overflow After a relatively short time, there is an multiplication overflow when multiplying (now - buft_start) with hda_bytes_per_second(). While the uptime now - buft_start only overflows after 2**63 ns = 292.27 years, this happens hda_bytes_per_second() times faster with the multiplication. At 44100 samples/s * 2 channels * 2 bytes/channel = 176400 bytes/s that is 14.52 hours. After the multiplication overflow the affected audio stream stalls. Replace the multiplication and following division with muldiv64() to prevent a multiplication overflow. Fixes: 280c1e1cdb ("audio/hda: create millisecond timers that handle IO") Reported-by: M_O_Bz <m_o_bz@163.com> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Message-Id: <20231105172552.8405-1-vr_qemu@t-online.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 74e8593e7e51d6b11ae9c56a3f4e7bb714bac4ec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
66f14b7 hw/avr/atmega: Fix wrong initial value of stack pointer The current implementation initializes the stack pointer of AVR devices to 0. Although older AVR devices used to be like that, newer ones set it to RAMEND. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1525 Signed-off-by: Gihun Nam <gihun.nam@outlook.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <PH0P222MB0010877445B594724D40C924DEBDA@PH0P222MB0010.NAMP222.PROD.OUTLOOK.COM> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 235948bf53860a1e2df5134eae7b0a30a971a124) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
fbca2cb hw/virtio: Add VirtioPCIDeviceTypeInfo::instance_finalize field The VirtioPCIDeviceTypeInfo structure, added in commit a4ee4c8baa ("virtio: Helper for registering virtio device types") got extended in commit 8ea90ee690 ("virtio: add class_size") with the @class_size field. Do similarly with the @instance_finalize field. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231121174051.63038-2-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 837053a7f491b445088eac647abe7f462c50f59a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
f5584a7 hw/nvram/xlnx-efuse-ctrl: Free XlnxVersalEFuseCtrl[] "pg0-lock" array Commit 0be6bfac62 ("qdev: Implement variable length array properties") added the DEFINE_PROP_ARRAY() macro with the following comment: * It is the responsibility of the device deinit code to free the * @_arrayfield memory. Commit 9e4aa1fafe added: DEFINE_PROP_ARRAY("pg0-lock", XlnxVersalEFuseCtrl, extra_pg0_lock_n16, extra_pg0_lock_spec, qdev_prop_uint16, uint16_t), but forgot to free the 'extra_pg0_lock_spec' array. Do it in the instance_finalize() handler. Cc: qemu-stable@nongnu.org Fixes: 9e4aa1fafe ("hw/nvram: Xilinx Versal eFuse device") # v6.2.0+ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231121174051.63038-6-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 4f10c66077e39969940d928077560665e155cac8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
a3e4630 hw/nvram/xlnx-efuse: Free XlnxEFuse::ro_bits[] array on finalize() Commit 0be6bfac62 ("qdev: Implement variable length array properties") added the DEFINE_PROP_ARRAY() macro with the following comment: * It is the responsibility of the device deinit code to free the * @_arrayfield memory. Commit 68fbcc344e added: DEFINE_PROP_ARRAY("read-only", XlnxEFuse, ro_bits_cnt, ro_bits, qdev_prop_uint32, uint32_t), but forgot to free the 'ro_bits' array. Do it in the instance_finalize handler. Cc: qemu-stable@nongnu.org Fixes: 68fbcc344e ("hw/nvram: Introduce Xilinx eFuse QOM") # v6.2.0+ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231121174051.63038-5-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 49b3e28b7bdfe771150d05c4b5860aa7854a4232) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
48e0dfb hw/misc/mps2-scc: Free MPS2SCC::oscclk[] array on finalize() Commit 0be6bfac62 ("qdev: Implement variable length array properties") added the DEFINE_PROP_ARRAY() macro with the following comment: * It is the responsibility of the device deinit code to free the * @_arrayfield memory. Commit 4fb013afcc added: DEFINE_PROP_ARRAY("oscclk", MPS2SCC, num_oscclk, oscclk_reset, qdev_prop_uint32, uint32_t), but forgot to free the 'oscclk_reset' array. Do it in the instance_finalize() handler. Cc: qemu-stable@nongnu.org Fixes: 4fb013afcc ("hw/misc/mps2-scc: Support configurable number of OSCCLK values") # v6.0.0+ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231121174051.63038-4-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 896dd6ff7b9f2575f1a908a07f26a70b58d8b675) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
502f15d hw/virtio: Free VirtIOIOMMUPCI::vdev.reserved_regions[] on finalize() Commit 0be6bfac62 ("qdev: Implement variable length array properties") added the DEFINE_PROP_ARRAY() macro with the following comment: * It is the responsibility of the device deinit code to free the * @_arrayfield memory. Commit 8077b8e549 added: DEFINE_PROP_ARRAY("reserved-regions", VirtIOIOMMUPCI, vdev.nb_reserved_regions, vdev.reserved_regions, qdev_prop_reserved_region, ReservedRegion), but forgot to free the 'vdev.reserved_regions' array. Do it in the instance_finalize() handler. Cc: qemu-stable@nongnu.org Fixes: 8077b8e549 ("virtio-iommu-pci: Add array of Interval properties") # v5.1.0+ Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20231121174051.63038-3-philmd@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit c9a4aa06dfce0fde1e279e1ea0c1945582ec0d16) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup hw/virtio/virtio-iommu-pci.c for before v8.1.0-2552-g41cc70cdf5, "virtio-iommu: Rename reserved_regions into prop_resv_regions" -- so now patch subject matches actual change again) 05 December 2023, 09:32:36 UTC
4972756 target/arm: Handle overflow in calculation of next timer tick In commit edac4d8a168 back in 2015 when we added support for the virtual timer offset CNTVOFF_EL2, we didn't correctly update the timer-recalculation code that figures out when the timer interrupt is next going to change state. We got it wrong in two ways: * for the 0->1 transition, we didn't notice that gt->cval + offset can overflow a uint64_t * for the 1->0 transition, we didn't notice that the transition might now happen before the count rolls over, if offset > count In the former case, we end up trying to set the next interrupt for a time in the past, which results in QEMU hanging as the timer fires continuously. In the latter case, we would fail to update the interrupt status when we are supposed to. Fix the calculations in both cases. The test case is Alex Bennée's from the bug report, and tests the 0->1 transition overflow case. Fixes: edac4d8a168 ("target-arm: Add CNTVOFF_EL2") Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/60 Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231120173506.3729884-1-peter.maydell@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 8d37a1425b9954d7e445615dcad23456515e24c0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
169c593 target/arm: Set IL bit for pauth, SVE access, BTI trap syndromes The syndrome register value always has an IL field at bit 25, which is 0 for a trap on a 16 bit instruction, and 1 for a trap on a 32 bit instruction (or for exceptions which aren't traps on a known instruction, like PC alignment faults). This means that our syn_*() functions should always either take an is_16bit argument to determine whether to set the IL bit, or else unconditionally set it. We missed setting the IL bit for the syndrome for three kinds of trap: * an SVE access exception * a pointer authentication check failure * a BTI (branch target identification) check failure All of these traps are AArch64 only, and so the instruction causing the trap is always 64 bit. This means we can unconditionally set the IL bit in the syn_*() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20231120150121.3458408-1-peter.maydell@linaro.org Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 11a3c4a286d5dc603582ea0a1fca62c2ec0a1aee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:36 UTC
5cf2cf1 vmdk: Don't corrupt desc file in vmdk_write_cid If the text description file is larger than DESC_SIZE, we force the last byte in the buffer to be 0 and write it out. This results in a corruption. Try to allocate a big buffer in this case. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1923 Signed-off-by: Fam Zheng <fam@euphon.net> Message-ID: <20231124115654.3239137-1-fam@euphon.net> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 9fb7b350ba9816ebca8a7614fec486fd4269ab2d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 05 December 2023, 09:32:35 UTC
6f51114 target/riscv/cpu_helper.c: Fix mxr bit behavior According to RISCV Specification sect 9.5 on two stage translation when V=1 the vsstatus(mstatus in QEMU's terms) field MXR, which makes execute-only pages readable, only overrides VS-stage page protection. Setting MXR at HS-level(mstatus_hs), however, overrides both VS-stage and G-stage execute-only permissions. The hypervisor extension changes the behavior of MXR\MPV\MPRV bits. Due to RISCV Specification sect. 9.4.1 when MPRV=1, explicit memory accesses are translated and protected, and endianness is applied, as though the current virtualization mode were set to MPV and the current nominal privilege mode were set to MPP. vsstatus.MXR makes readable those pages marked executable at the VS translation stage. Fixes: 36a18664ba ("target/riscv: Implement second stage MMU") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-3-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 6bca4d7d1ff2b8857486c3ff31f5c6fc3e3984b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 13:15:22 UTC
87ff608 target/riscv/cpu_helper.c: Invalid exception on MMU translation stage According to RISCV privileged spec sect. 5.3.2 Virtual Address Translation Process access-fault exceptions may raise only after PMA/PMP check. Current implementation generates an access-fault for mbare mode even if there were no PMA/PMP errors. This patch removes the erroneous MMU mode check and generates an access-fault exception based on the pmp_violation flag only. Fixes: 1448689c7b ("target/riscv: Allow specifying MMU stage") Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231121071757.7178-2-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 82d53adfbb1aa0dbe7dac09b61ad86014efe81a7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 13:15:22 UTC
837148a riscv: Fix SiFive E CLINT clock frequency If you check the manual of SiFive E310 (https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf), you can see in Figure 1 that the CLINT is connected to the real time clock, which also feeds the AON peripheral (they share the same clock). In page 43, the docs also say that the timer registers of the CLINT count ticks from the rtcclk. I am currently playing with bare metal applications both in QEMU and a physical SiFive E310 board and I confirm that the CLINT clock in the physical board runs at 32.768 kHz. In QEMU, the same app produces a completely different outcome, as sometimes a new CLINT interrupt is triggered before finishing other tasks. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1978 Signed-off-by: Rom\ufffd\ufffdn C\ufffd\ufffdrdenas <rcardenas.rod@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231117082840.55705-1-rcardenas.rod@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit a7472560ca5f7a61ef3a46b52118f680de81058c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 13:15:22 UTC
9ac7606 hw/riscv/virt.c: do create_fdt() earlier, add finalize_fdt() Commit 49554856f0 fixed a problem, where TPM devices were not appearing in the FDT, by delaying the FDT creation up until virt_machine_done(). This create a side effect (see gitlab #1925) - devices that need access to the '/chosen' FDT node during realize() stopped working because, at that point, we don't have a FDT. This happens because our FDT creation is monolithic, but it doesn't need to be. We can add the needed FDT components for realize() time and, at the same time, do another FDT round where we account for dynamic sysbus devices. In other words, the problem fixed by 49554856f0 could also be fixed by postponing only create_fdt_sockets() and its dependencies, leaving everything else from create_fdt() to be done during init(). Split the FDT creation in two parts: - create_fdt(), now moved back to virt_machine_init(), will create FDT nodes that doesn't depend on additional (dynamic) devices from the sysbus; - a new finalize_fdt() step is added, where create_fdt_sockets() and friends is executed, accounting for the dynamic sysbus devices that were added during realize(). This will make both use cases happy: TPM devices are still working as intended, and devices such as 'guest-loader' have a FDT to work on during realize(). Fixes: 49554856f0 ("riscv: Generate devicetree only after machine initialization is complete") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1925 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231110172559.73209-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 7a87ba8956e59bec8cc4677c6aa5141e4c023a7d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 13:15:22 UTC
8d0b8fe linux-user/riscv: Add Zicboz block size to hwprobe Support for probing the Zicboz block size landed in Linux 6.6, which was released a few weeks ago. This provides the user-configured block size when Zicboz is enabled. Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231110173716.24423-1-palmer@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 301c65f49f9602f39b9f3ce0ad9ff70d4bda7226) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup linux-user/syscall.c to before v8.1.0-2602-ge57039ddab "target/riscv: rename ext_icboz to ext_zicboz") 29 November 2023, 13:14:17 UTC
8328d79 tests/avocado: Replace assertRegexpMatches() for Python 3.12 compatibility assertRegexpMatches() has been removed in Python 3.12 and should be replaced by assertRegex(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3 Inspired-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231114144832.71612-1-philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit f0a663b4ced2bf315936c774c2b6ff398fce8905) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: adjust context for before v8.1.0-1582-g684750ab4f "python/qemu: rename command() to cmd()") 29 November 2023, 12:35:38 UTC
5e7f6af tests/avocado: Replace assertEquals() for Python 3.12 compatibility assertEquals() has been removed in Python 3.12 and should be replaced by assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3 Message-ID: <20231114134326.287242-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 861f724d03e1748cda1c5b9ec8457a368590cbd5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: adjust context in pc_cpu_hotplug_props.py & cpu_queries.py for before v8.1.0-1582-g684750ab4f "python/qemu: rename command() to cmd()") 29 November 2023, 12:35:38 UTC
983a4a8 linux-user: Fix loaddr computation for some elf files The file offset of the load segment is not relevant to the low address, only the beginning of the virtual address page. Cc: qemu-stable@nongnu.org Fixes: a93934fecd4 ("elf: take phdr offset into account when calculating the program load address") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1952 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 82d70a84c8ee42ef969a9cfddc0f5b30b16165f5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 12:35:38 UTC
88e79a2 net: Update MemReentrancyGuard for NIC Recently MemReentrancyGuard was added to DeviceState to record that the device is engaging in I/O. The network device backend needs to update it when delivering a packet to a device. This implementation follows what bottom half does, but it does not add a tracepoint for the case that the network device backend started delivering a packet to a device which is already engaging in I/O. This is because such reentrancy frequently happens for qemu_flush_queued_packets() and is insignificant. Fixes: CVE-2023-3019 Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 29 November 2023, 12:35:38 UTC
cc5124d net: Provide MemReentrancyGuard * to qemu_new_nic() Recently MemReentrancyGuard was added to DeviceState to record that the device is engaging in I/O. The network device backend needs to update it when delivering a packet to a device. In preparation for such a change, add MemReentrancyGuard * as a parameter of qemu_new_nic(). Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 7d0fefdf81f5973334c344f6b8e1896c309dff66) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: fixup in hw/net/xen_nic.c due to lack of v8.1.0-2771-g25967ff69f "hw/xen: update Xen PV NIC to XenDevice model") 29 November 2023, 12:33:42 UTC
c6c0a18 hw/ide/ahci: fix legacy software reset Legacy software contains a standard mechanism for generating a reset to a Serial ATA device - setting the SRST (software reset) bit in the Device Control register. Serial ATA has a more robust mechanism called COMRESET, also referred to as port reset. A port reset is the preferred mechanism for error recovery and should be used in place of software reset. Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling") (mjt: 16cc9594d23d in stable-8.1 series, v8.1.1) improved the handling of PxCI, such that PxCI gets cleared after handling a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after receiving anything - even a FIS that failed to parse, which should NOT clear PxCI, so that you can see which command slot that caused an error). However, simply clearing PxCI after a non-NCQ, or NCQ command, is not enough, we also need to clear PxCI when receiving a SRST in the Device Control register. A legacy software reset is performed by the host sending two H2D FISes, the first H2D FIS asserts SRST, and the second H2D FIS deasserts SRST. The first H2D FIS will not get a D2H reply, and requires the FIS to have the C bit set to one, such that the HBA itself will clear the bit in PxCI. The second H2D FIS will get a D2H reply once the diagnostic is completed. The clearing of the bit in PxCI for this command should ideally be done in ahci_init_d2h() (if it was a legacy software reset that caused the reset (a COMRESET does not use a command slot)). However, since the reset value for PxCI is 0, modify ahci_reset_port() to actually clear PxCI to 0, that way we can avoid complex logic in ahci_init_d2h(). This fixes an issue for FreeBSD where the device would fail to reset. The problem was not noticed in Linux, because Linux uses a COMRESET instead of a legacy software reset by default. Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling") Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com> Message-ID: <20231108222657.117984-1-nks@flawful.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit eabb921250666501ae78714b60090200b639fcfe) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (mjt: mention 16cc9594d23d for stable-8.1) 22 November 2023, 11:25:22 UTC
db8e86c target/arm: Fix SME FMOPA (16-bit), BFMOPA Perform the loop increment unconditionally, not nested within the predication. Cc: qemu-stable@nongnu.org Fixes: 3916841ac75 ("target/arm: Implement FMOPA, FMOPS (widening)") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1985 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231117193135.1180657-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 3efd8495735c69b863476e9003e624877382a72d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 November 2023, 11:25:22 UTC
d8ad972 linux-user: xtensa: fix signal delivery in FDPIC In FDPIC signal handlers are passed around as FD pointers. Actual code address and GOT pointer must be fetched from memory by the QEMU code that implements kernel signal delivery functionality. This change is equivalent to the following kernel change: 9c2cc74fb31e ("xtensa: fix signal delivery to FDPIC process") Cc: qemu-stable@nongnu.org Fixes: d2796be69d7c ("linux-user: add support for xtensa FDPIC") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 1b173d06068c4a4e93fad88205399232925967a4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 22 November 2023, 11:25:22 UTC
179cc58 Update version for 8.1.3 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 21 November 2023, 09:00:46 UTC
d19b4a4 hw/mips: LOONGSON3V depends on UNIMP device Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: qemu-stable@nongnu.org Fixes: c76b409fef ("hw/mips: Add Loongson-3 machine support") Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231107140615.3034763-1-marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 52c773ce893f6321f20c80101aa4ea9489a6f701) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
b88b958 target/arm: HVC at EL3 should go to EL3, not EL2 AArch64 permits code at EL3 to use the HVC instruction; however the exception we take should go to EL3, not down to EL2 (see the pseudocode AArch64.CallHypervisor()). Fix the target EL. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Message-id: 20231109151917.1925107-1-peter.maydell@linaro.org (cherry picked from commit fc58891d0422607d172a3d6b3158798f2556aef1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
25f5550 s390x/pci: only limit DMA aperture if vfio DMA limit reported If the host kernel lacks vfio DMA limit reporting, do not attempt to shrink the guest DMA aperture. Fixes: df202e3ff3 ("s390x/pci: shrink DMA aperture to be bound by vfio DMA limit") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-ID: <20231110175108.465851-3-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 8011b508cf0ddbdbda03820f4fa6cd484a6d9aed) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
150ebd0 target/riscv/kvm: support KVM_GET_REG_LIST KVM for RISC-V started supporting KVM_GET_REG_LIST in Linux 6.6. It consists of a KVM ioctl() that retrieves a list of all available regs for get_one_reg/set_one_reg. Regs that aren't present in the list aren't supported in the host. This simplifies our lives when initing the KVM regs since we don't have to always attempt a KVM_GET_ONE_REG for all regs QEMU knows. We'll only attempt a get_one_reg() if we're sure the reg is supported, i.e. it was retrieved by KVM_GET_REG_LIST. Any error in get_one_reg() will then always considered fatal, instead of having to handle special error codes that might indicate a non-fatal failure. Start by moving the current kvm_riscv_init_multiext_cfg() logic into a new kvm_riscv_read_multiext_legacy() helper. We'll prioritize using KVM_GET_REG_LIST, so check if we have it available and, in case we don't, use the legacy() logic. Otherwise, retrieve the available reg list and use it to check if the host supports our known KVM regs, doing the usual get_one_reg() for the supported regs and setting cpu->cfg accordingly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231003132148.797921-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 608bdebb6075b757e5505f6bbc60c45a54a1390b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial context tweak in target/riscv/kvm.c) 19 November 2023, 18:15:06 UTC
221c0e1 target/riscv/kvm: improve 'init_multiext_cfg' error msg Our error message is returning the value of 'ret', which will be always -1 in case of error, and will not be that useful: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error -1 Improve the error message by outputting 'errno' instead of 'ret'. Use strerrorname_np() to output the error name instead of the error code. This will give us what we need to know right away: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error code: ENOENT Given that we're going to exit(1) in this condition instead of attempting to recover, remove the 'kvm_riscv_destroy_scratch_vcpu()' call. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231003132148.797921-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 082e9e4a58ba80ec056220a2f762a1c6b9a3a96c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
100feda tracetool: avoid invalid escape in Python string This is an error in Python 3.12; fix it by using a raw string literal. Cc: <qemu-stable@nongnu.org> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231108105649.60453-1-marcandre.lureau@redhat.com> (cherry picked from commit 4d96307c5b4fac40c6ca25f38318b4b65d315de0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
097c347 tests/tcg/s390x: Test LAALG with negative cc_src Add a small test to prevent regressions. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231106093605.1349201-5-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit ebc14107f1f3ac1db13132cd28cf94adcd38e5d7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
a16eec9 target/s390x: Fix LAALG not updating cc_src LAALG uses op_laa() and wout_addu64(). The latter expects cc_src to be set, but the former does not do it. This can lead to assertion failures if something sets cc_src to neither 0 nor 1 before. Fix by introducing op_laa_addu64(), which sets cc_src, and using it for LAALG. Fixes: 4dba4d6fef61 ("target/s390x: Use atomic operations for LOAD AND OP") Cc: qemu-stable@nongnu.org Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231106093605.1349201-4-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit bea402482a8c94389638cbd3d7fe3963fb317f4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
255422d tests/tcg/s390x: Test CLC with inaccessible second operand Add a small test to prevent regressions. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231106093605.1349201-3-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 43fecbe7a53fe8e5a6aff0d6471b1cc624e26b51) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
88b778e target/s390x: Fix CLC corrupting cc_src CLC updates cc_src before accessing the second operand; if the latter is inaccessible, the former ends up containing a bogus value. Fix by reading cc_src into a temporary first. Fixes: 4f7403d52b1c ("target-s390: Convert CLC") Closes: https://gitlab.com/qemu-project/qemu/-/issues/1865 Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-ID: <20231106093605.1349201-2-iii@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit aba2ec341c6d20c8dc3e6ecf87fa7c1a71e30c1e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
07c2a9c tests/qtest: ahci-test: add test exposing reset issue with pending callback Before commit "hw/ide: reset: cancel async DMA operation before resetting state", this test would fail, because a reset with a pending write operation would lead to an unsolicited write to the first sector of the disk. The test writes a pattern to the beginning of the disk and verifies that it is still intact after a reset with a pending operation. It also checks that the pending operation actually completes correctly. Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Message-ID: <20230906130922.142845-2-f.ebner@proxmox.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit cc610857bbd3551f4b86ae2299336b5d9aa0db2b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
60f7b60 hw/ide: reset: cancel async DMA operation before resetting state If there is a pending DMA operation during ide_bus_reset(), the fact that the IDEState is already reset before the operation is canceled can be problematic. In particular, ide_dma_cb() might be called and then use the reset IDEState which contains the signature after the reset. When used to construct the IO operation this leads to ide_get_sector() returning 0 and nsector being 1. This is particularly bad, because a write command will thus destroy the first sector which often contains a partition table or similar. Traces showing the unsolicited write happening with IDEState 0x5595af6949d0 being used after reset: > ahci_port_write ahci(0x5595af6923f0)[0]: port write [reg:PxSCTL] @ 0x2c: 0x00000300 > ahci_reset_port ahci(0x5595af6923f0)[0]: reset port > ide_reset IDEstate 0x5595af6949d0 > ide_reset IDEstate 0x5595af694da8 > ide_bus_reset_aio aio_cancel > dma_aio_cancel dbs=0x7f64600089a0 > dma_blk_cb dbs=0x7f64600089a0 ret=0 > dma_complete dbs=0x7f64600089a0 ret=0 cb=0x5595acd40b30 > ahci_populate_sglist ahci(0x5595af6923f0)[0] > ahci_dma_prepare_buf ahci(0x5595af6923f0)[0]: prepare buf limit=512 prepared=512 > ide_dma_cb IDEState 0x5595af6949d0; sector_num=0 n=1 cmd=DMA WRITE > dma_blk_io dbs=0x7f6420802010 bs=0x5595ae2c6c30 offset=0 to_dev=1 > dma_blk_cb dbs=0x7f6420802010 ret=0 > (gdb) p *qiov > $11 = {iov = 0x7f647c76d840, niov = 1, {{nalloc = 1, local_iov = {iov_base = 0x0, > iov_len = 512}}, {__pad = "\001\000\000\000\000\000\000\000\000\000\000", > size = 512}}} > (gdb) bt > #0 blk_aio_pwritev (blk=0x5595ae2c6c30, offset=0, qiov=0x7f6420802070, flags=0, > cb=0x5595ace6f0b0 <dma_blk_cb>, opaque=0x7f6420802010) > at ../block/block-backend.c:1682 > #1 0x00005595ace6f185 in dma_blk_cb (opaque=0x7f6420802010, ret=<optimized out>) > at ../softmmu/dma-helpers.c:179 > #2 0x00005595ace6f778 in dma_blk_io (ctx=0x5595ae0609f0, > sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, > io_func=io_func@entry=0x5595ace6ee30 <dma_blk_write_io_func>, > io_func_opaque=io_func_opaque@entry=0x5595ae2c6c30, > cb=0x5595acd40b30 <ide_dma_cb>, opaque=0x5595af6949d0, > dir=DMA_DIRECTION_TO_DEVICE) at ../softmmu/dma-helpers.c:244 > #3 0x00005595ace6f90a in dma_blk_write (blk=0x5595ae2c6c30, > sg=sg@entry=0x5595af694d00, offset=offset@entry=0, align=align@entry=512, > cb=cb@entry=0x5595acd40b30 <ide_dma_cb>, opaque=opaque@entry=0x5595af6949d0) > at ../softmmu/dma-helpers.c:280 > #4 0x00005595acd40e18 in ide_dma_cb (opaque=0x5595af6949d0, ret=<optimized out>) > at ../hw/ide/core.c:953 > #5 0x00005595ace6f319 in dma_complete (ret=0, dbs=0x7f64600089a0) > at ../softmmu/dma-helpers.c:107 > #6 dma_blk_cb (opaque=0x7f64600089a0, ret=0) at ../softmmu/dma-helpers.c:127 > #7 0x00005595ad12227d in blk_aio_complete (acb=0x7f6460005b10) > at ../block/block-backend.c:1527 > #8 blk_aio_complete (acb=0x7f6460005b10) at ../block/block-backend.c:1524 > #9 blk_aio_write_entry (opaque=0x7f6460005b10) at ../block/block-backend.c:1594 > #10 0x00005595ad258cfb in coroutine_trampoline (i0=<optimized out>, > i1=<optimized out>) at ../util/coroutine-ucontext.c:177 Signed-off-by: Fiona Ebner <f.ebner@proxmox.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: simon.rowe@nutanix.com Message-ID: <20230906130922.142845-1-f.ebner@proxmox.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 7d7512019fc40c577e2bdd61f114f31a9eb84a8e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
f15258b target/mips: Fix TX79 LQ/SQ opcodes The base register address offset is *signed*. Cc: qemu-stable@nongnu.org Fixes: aaaa82a9f9 ("target/mips/tx79: Introduce LQ opcode (Load Quadword)") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230914090447.12557-1-philmd@linaro.org> (cherry picked from commit 18f86aecd6a1bea0f78af14587a684ad966d8d3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
f68a36b target/mips: Fix MSA BZ/BNZ opcodes displacement The PC offset is *signed*. Cc: qemu-stable@nongnu.org Reported-by: Sergey Evlashev <vectorchiefrocks@gmail.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1624 Fixes: c7a9ef7517 ("target/mips: Introduce decode tree bindings for MSA ASE") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230914085807.12241-1-philmd@linaro.org> (cherry picked from commit 04591b3ddd9a96b9298a1dd437a6464ab55e62ee) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 19 November 2023, 18:15:06 UTC
801b7e4 ui/gtk-egl: apply scale factor when calculating window's dimension Scale factor needs to be applied when calculating width/height of the GTK windows. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20231012222643.13996-1-dongwon.kim@intel.com> (cherry picked from commit 47fd6ab1e334962890bc3e8d2e32857f6594e1c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
30d90ae ui/gtk: force realization of drawing area Fixes the GL context creation from a widget that isn't yet realized (in a hidden tab for example). Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1727 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Antonio Caggiano <quic_acaggian@quicinc.com> Message-Id: <20231017111642.1155545-1-marcandre.lureau@redhat.com> (cherry picked from commit 565f85a9c293818a91a3d3414311303de7e00cec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
e301a77 ati-vga: Implement fallback for pixman routines Pixman routines can fail if no implementation is available and it will become optional soon so add fallbacks when pixman does not work. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <ed0fba3f74e48143f02228b83bf8796ca49f3e7d.1698871239.git.balaton@eik.bme.hu> (cherry picked from commit 08730ee0cc01c3fceb907a93436d15170a7556c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
bcc9879 file-posix: fix over-writing of returning zone_append offset raw_co_zone_append() sets "s->offset" where "BDRVRawState *s". This pointer is used later at raw_co_prw() to save the block address where the data is written. When multiple IOs are on-going at the same time, a later IO's raw_co_zone_append() call over-writes a former IO's offset address before raw_co_prw() completes. As a result, the former zone append IO returns the initial value (= the start address of the writing zone), instead of the proper address. Fix the issue by passing the offset pointer to raw_co_prw() instead of passing it through s->offset. Also, remove "offset" from BDRVRawState as there is no usage anymore. Fixes: 4751d09adcc3 ("block: introduce zone append write for zoned devices") Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Message-Id: <20231030073853.2601162-1-naohiro.aota@wdc.com> Reviewed-by: Sam Li <faithilikerun@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Hanna Czenczek <hreitz@redhat.com> (cherry picked from commit ad4feaca61d76fecad784e6d5e7bae40d0411c46) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
a753815 block/file-posix: fix update_zones_wp() caller When the zoned request fail, it needs to update only the wp of the target zones for not disrupting the in-flight writes on these other zones. The wp is updated successfully after the request completes. Fixed the callers with right offset and nr_zones. Signed-off-by: Sam Li <faithilikerun@gmail.com> Message-Id: <20230825040556.4217-1-faithilikerun@gmail.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> [hreitz: Rebased and fixed comment spelling] Signed-off-by: Hanna Czenczek <hreitz@redhat.com> (cherry picked from commit 10b9e0802a074c991e1ce485631d75641d0b0f9e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
cc9f53b qcow2: keep reference on zeroize with discard-no-unref enabled When the discard-no-unref flag is enabled, we keep the reference for normal discard requests. But when a discard is executed on a snapshot/qcow2 image with backing, the discards are saved as zero clusters in the snapshot image. When committing the snapshot to the backing file, not discard_in_l2_slice is called but zero_in_l2_slice. Which did not had any logic to keep the reference when discard-no-unref is enabled. Therefor we add logic in the zero_in_l2_slice call to keep the reference on commit. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1621 Signed-off-by: Jean-Louis Dupond <jean-louis@dupond.be> Message-Id: <20231003125236.216473-2-jean-louis@dupond.be> [hreitz: Made the documentation change more verbose, as discussed on-list] Signed-off-by: Hanna Czenczek <hreitz@redhat.com> (cherry picked from commit b2b109041ecd1095384f5be5bb9badd13c1cf286) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
fe8eb31 target/arm: Fix A64 LDRA immediate decode In commit be23a049 in the conversion to decodetree we broke the decoding of the immediate value in the LDRA instruction. This should be a 10 bit signed value that is scaled by 8, but in the conversion we incorrectly ended up scaling it only by 2. Fix the scaling factor. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1970 Fixes: be23a049 ("target/arm: Convert load (pointer auth) insns to decodetree") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20231106113445.1163063-1-peter.maydell@linaro.org (cherry picked from commit 5722fc471296d5f042df4b005a851cc8008df0c9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
1f560fa block/nvme: nvme_process_completion() fix bound for cid NVMeQueuePair::reqs has length NVME_NUM_REQS, which less than NVME_QUEUE_SIZE by 1. Fixes: 1086e95da17050 ("block/nvme: switch to a NVMeRequest freelist") Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Maksim Davydov <davydov-max@yandex-team.ru> Message-id: 20231017125941.810461-5-vsementsov@yandex-team.ru Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit cc8fb0c3ae3c950eb40e969607e17ff16a7519ac) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
a89c8b9 virtio-gpu: block migration of VMs with blob=true "blob" resources don't have an associated pixman image: #0 pixman_image_get_stride (image=0x0) at ../pixman/pixman-image.c:921 #1 0x0000562327c25236 in virtio_gpu_save (f=0x56232bb13b00, opaque=0x56232b555a60, size=0, field=0x5623289ab6c8 <__compound_literal.3+104>, vmdesc=0x56232ab59fe0) at ../hw/display/virtio-gpu.c:1225 Related to: https://bugzilla.redhat.com/show_bug.cgi?id=2236353 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 9c549ab6895a43ad0cb33e684e11cdb0b5400897) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
2873034 hw/xen: use correct default protocol for xen-block on x86 Even on x86_64 the default protocol is the x86-32 one if the guest doesn't specifically ask for x86-64. Cc: qemu-stable@nongnu.org Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and disconnect functions...") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit a1c1082908dde4867b1ac55f546bea0c17d52318) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
30a4cc2 hw/xen: take iothread mutex in xen_evtchn_reset_op() The xen_evtchn_soft_reset() function requires the iothread mutex, but is also called for the EVTCHNOP_reset hypercall. Ensure the mutex is taken in that case. Cc: qemu-stable@nongnu.org Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit debc995e883b05c2fd02fb797a61ab1328e5bae2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
b644416 hw/xen: fix XenStore watch delivery to guest When fire_watch_cb() found the response buffer empty, it would call deliver_watch() to generate the XS_WATCH_EVENT message in the response buffer and send an event channel notification to the guest… without actually *copying* the response buffer into the ring. So there was nothing for the guest to see. The pending response didn't actually get processed into the ring until the guest next triggered some activity from its side. Add the missing call to put_rsp(). It might have been slightly nicer to call xen_xenstore_event() here, which would *almost* have worked. Except for the fact that it calls xen_be_evtchn_pending() to check that it really does have an event pending (and clear the eventfd for next time). And under Xen it's defined that setting that fd to O_NONBLOCK isn't guaranteed to work, so the emu implementation follows suit. This fixes Xen device hot-unplug. Cc: qemu-stable@nongnu.org Fixes: 0254c4d19df ("hw/xen: Add xenstore wire implementation and implementation stubs") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit 4a5780f52095f1daf23618dc6198a2a1665ea505) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
0f2dd05 hw/xen: don't clear map_track[] in xen_gnttab_reset() The refcounts actually correspond to 'active_ref' structures stored in a GHashTable per "user" on the backend side (mostly, per XenDevice). If we zero map_track[] on reset, then when the backend drivers get torn down and release their mapping we hit the assert(s->map_track[ref] != 0) in gnt_unref(). So leave them in place. Each backend driver will disconnect and reconnect as the guest comes back up again and reconnects, and it all works out OK in the end as the old refs get dropped. Cc: qemu-stable@nongnu.org Fixes: de26b2619789 ("hw/xen: Implement soft reset for emulated gnttab") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> (cherry picked from commit 3de75ed352411899dbc9222e82fe164890c77e78) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> 09 November 2023, 13:39:13 UTC
back to top