aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-29Update version for 7.2.9 releasev7.2.9Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-01-27target/xtensa: fix OOB TLB entry accessMax Filippov
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>
2024-01-26qtest: bump aspeed_smc-test timeout to 6 minutesDaniel P. Berrangé
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)
2024-01-26monitor: only run coroutine commands in qemu_aio_contextStefan Hajnoczi
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> (Mjt: omit changes to tests missing in 7.2)
2024-01-26iotests: port 141 to Python for reliable QMP testingStefan Hajnoczi
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>
2024-01-26iotests: add filter_qmp_generated_node_ids()Stefan Hajnoczi
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> (Mjt: context fix in tests/qemu-iotests/iotests.py due to v7.2.0-939-gbcc6777ad6 "iotests: Filter child node information")
2024-01-26block/blklogwrites: Fix a bug when logging "write zeroes" operations.Ari Sundholm
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>
2024-01-26virtio-net: correctly copy vnet header when flushing TXJason Wang
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>
2024-01-25block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_statusFiona Ebner
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>
2024-01-25accel/tcg: Revert mapping of PCREL translation block to multiple virtual ↵Paolo Bonzini
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>
2024-01-23readthodocs: fully specify a build environmentAlex Bennée
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>
2024-01-20hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issuedMark Cave-Ayland
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>
2024-01-20hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion ↵Mark Cave-Ayland
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>
2024-01-20hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sourcesMark Cave-Ayland
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> (Mjt: fixup in hw/scsi/esp-pci.c due to v8.0.0-1556-g7d5b0d6864 "bulk: Remove pointless QOM casts")
2024-01-20hw/scsi/esp-pci: use correct address register for PCI DMA transfersMark Cave-Ayland
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>
2024-01-20hw/pflash: implement update buffer for block writesGerd Hoffmann
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")
2024-01-20hw/pflash: use ldn_{be,le}_p and stn_{be,le}_pGerd Hoffmann
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>
2024-01-20hw/pflash: refactor pflash_data_write()Gerd Hoffmann
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>
2024-01-20target/i386: pcrel: store low bits of physical address in data[0]Paolo Bonzini
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> (Mjt: fixup in target/i386/tcg/tcg-cpu.c target/i386/tcg/translate.c for v7.2.0-1839-g2e3afe8e19 "target/i386: Replace `TARGET_TB_PCREL` with `CF_PCREL`")
2024-01-20target/i386: fix incorrect EIP in PC-relative translation blocksguoguangyao
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") 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>
2024-01-20target/i386: Do not re-compute new pc with CF_PCRELRichard Henderson
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") 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>
2024-01-20target/i386: Fix 32-bit wrapping of pc/eip computationRichard Henderson
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()") (Mjt: fixup in target/i386/tcg/tcg-cpu.c for v7.2.0-1854-g34a39c2443 "target/i386: Replace `tb_pc()` with `tb->pc`")
2024-01-19load_elf: fix iterator's type for elf file processingAnastasia Belova
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>
2024-01-13.gitlab-ci.d/buildtest.yml: Work around htags bug when environment is largePeter Maydell
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>
2024-01-13target/s390x: Fix LAE setting a wrong access registerIlya Leoshkevich
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" and v7.2.0-2636-g3ac6f91bca "target/s390x: Drop tcg_temp_free from translate.c")
2024-01-11hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registersPeter Maydell
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>
2024-01-08chardev/char.c: fix "abstract device type" error messageMichael Tokarev
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>
2024-01-08target/riscv: Fix mcycle/minstret increment behaviorXu Lu
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>
2023-12-22iotests: Basic tests for internal snapshotsKevin Wolf
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>
2023-12-22vl: Improve error message for conflicting -incoming and -loadvmKevin Wolf
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>
2023-12-22block: Fix crash when loading snapshot on inactive nodeKevin Wolf
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>
2023-12-22Update version for 7.2.8 releasev7.2.8Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-12-20target/arm/helper: Propagate MDCR_EL2.HPMN into PMCR_EL0.NJean-Philippe Brucker
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>
2023-12-20system/memory: use ldn_he_p/stn_he_pPatrick Venture
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>
2023-12-20target/arm: Disable SME if SVE is disabledPeter Maydell
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>
2023-12-20ui/vnc-clipboard: fix inflate_bufferFiona Ebner
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>
2023-12-20ui/gtk-egl: move function calls back to regular code pathVolker Rümelin
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>
2023-12-20ui/gtk-egl: Check EGLSurface before doing scanoutAntonio Caggiano
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>
2023-12-20msix: unset PCIDevice::msix_vector_poll_notifier in rollbackRobert Hoo
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>
2023-12-20hw/acpi/erst: Do not ignore Error* in realize handlerPhilippe Mathieu-Daudé
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>
2023-12-20pcie_sriov: Remove g_new assertionAkihiko Odaki
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>
2023-12-20hw/audio/hda-codec: fix multiplication overflowVolker Rümelin
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>
2023-12-20hw/mips/malta: Fix the malta machine on big endian hostsThomas Huth
Booting a Linux kernel with the malta machine is currently broken on big endian hosts. The cpu_to_gt32 macro wants to byteswap a value for little endian targets only, but uses the wrong way to do this: cpu_to_[lb]e32 works the other way round on big endian hosts! Fix it by using the same ways on both, big and little endian hosts. Fixes: 0c8427baf0 ("hw/mips/malta: Use bootloader helper to set BAR registers") Cc: qemu-stable@nongnu.org Message-Id: <20230330152613.232082-1-thuth@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit dc96009afd8cf2372fa1bbced0bcbcbb2c5d6f1b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: adjust context for before v7.2.0-677-g0e45355c5c)
2023-12-20vmdk: Don't corrupt desc file in vmdk_write_cidFam Zheng
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> (Mjt: fixups in block/vmdk.c due to missing-in-7.2 v8.0.0-2084-g28944f99c4 "vmdk: mark more functions as coroutine_fns and GRAPH_RDLOCK")
2023-12-20hw/virtio: Add VirtioPCIDeviceTypeInfo::instance_finalize fieldPhilippe Mathieu-Daudé
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>
2023-12-20hw/nvram/xlnx-efuse-ctrl: Free XlnxVersalEFuseCtrl[] "pg0-lock" arrayPhilippe Mathieu-Daudé
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>
2023-12-20hw/nvram/xlnx-efuse: Free XlnxEFuse::ro_bits[] array on finalize()Philippe Mathieu-Daudé
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>
2023-12-20hw/misc/mps2-scc: Free MPS2SCC::oscclk[] array on finalize()Philippe Mathieu-Daudé
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>
2023-12-20hw/virtio: Free VirtIOIOMMUPCI::vdev.reserved_regions[] on finalize()Philippe Mathieu-Daudé
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)
2023-12-05target/arm: Set IL bit for pauth, SVE access, BTI trap syndromesPeter Maydell
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>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-30 11:03:55 +0000