Update 8.1 #33
Closed
Update 8.1 #33
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently the emulation of VSTRS recognizes partial matches in presence
of \0 in the haystack, which, according to PoP, is not correct:
If the ZS flag is one and a zero byte was detected
in the second operand, then there can not be a
partial match ...
Add a check for this. While at it, fold a number of explicitly handled
special cases into the generic logic.
Cc: [email protected]
Reported-by: Claudio Fontana <[email protected]>
Closes: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00633.html
Fixes: 1d706f3 ("target/s390x: vxeh2: vector string search")
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-Id: <[email protected]>
Tested-by: Claudio Fontana <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 791b2b6)
Signed-off-by: Michael Tokarev <[email protected]>
Unlike most other instructions that contain an immediate element index, VREP's one is 16-bit, and not 4-bit. The code uses only 8 bits, so using, e.g., 0x101 does not lead to a specification exception. Fix by checking all 16 bits. Cc: [email protected] Fixes: 28d0873 ("s390x/tcg: Implement VECTOR REPLICATE") Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Thomas Huth <[email protected]> (cherry picked from commit 23e87d4) Signed-off-by: Michael Tokarev <[email protected]>
The length is always truncated to 16 bytes. Do not probe more than that. Cc: [email protected] Fixes: 0e0a5b4 ("s390x/tcg: Implement VECTOR STORE WITH LENGTH") Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Thomas Huth <[email protected]> (cherry picked from commit 6db3518) Signed-off-by: Michael Tokarev <[email protected]>
VFMIN and VFMAX should raise a specification exceptions when bits 1-3 of M5 are set. Cc: [email protected] Fixes: da48075 ("s390x/tcg: Implement VECTOR FP (MAXIMUM|MINIMUM)") Signed-off-by: Ilya Leoshkevich <[email protected]> Message-Id: <[email protected]> Reviewed-by: David Hildenbrand <[email protected]> Signed-off-by: Thomas Huth <[email protected]> (cherry picked from commit 6a2ea61) Signed-off-by: Michael Tokarev <[email protected]>
…hosts Using "-device virtio-gpu,blob=true" currently does not work on big endian hosts (like s390x). The guest kernel prints an error message like: [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR* response 0x1200 (command 0x10c) and the display stays black. When running QEMU with "-d guest_errors", it shows an error message like this: virtio_gpu_create_mapping_iov: nr_entries is too big (83886080 > 16384) which indicates that this value has not been properly byte-swapped. And indeed, the virtio_gpu_create_blob_bswap() function (that should swap the fields in the related structure) fails to swap some of the entries. After correctly swapping all missing values here, too, the virtio-gpu device is now also working with blob=true on s390x hosts. Fixes: e0933d9 ("virtio-gpu: Add virtio_gpu_resource_create_blob") Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2230469 Message-Id: <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Signed-off-by: Thomas Huth <[email protected]> (cherry picked from commit d194362) Signed-off-by: Michael Tokarev <[email protected]>
kvm_arch_get_default_type() returns the default KVM type. This hook is particularly useful to derive a KVM type that is valid for "none" machine model, which is used by libvirt to probe the availability of KVM. For MIPS, the existing mips_kvm_type() is reused. This function ensures the availability of VZ which is mandatory to use KVM on the current QEMU. Cc: [email protected] Signed-off-by: Akihiko Odaki <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> [PMM: added doc comment for new function] Signed-off-by: Peter Maydell <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> (cherry picked from commit 5e0d659) Signed-off-by: Michael Tokarev <[email protected]>
Before this change, the default KVM type, which is used for non-virt machine models, was 0. The kernel documentation says: > On arm64, the physical address size for a VM (IPA Size limit) is > limited to 40bits by default. The limit can be configured if the host > supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use > KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type > identifier, where IPA_Bits is the maximum width of any physical > address used by the VM. The IPA_Bits is encoded in bits[7-0] of the > machine type identifier. > > e.g, to configure a guest to use 48bit physical address size:: > > vm_fd = ioctl(dev_fd, KVM_CREATE_VM, KVM_VM_TYPE_ARM_IPA_SIZE(48)); > > The requested size (IPA_Bits) must be: > > == ========================================================= > 0 Implies default size, 40bits (for backward compatibility) > N Implies N bits, where N is a positive integer such that, > 32 <= N <= Host_IPA_Limit > == ========================================================= > Host_IPA_Limit is the maximum possible value for IPA_Bits on the host > and is dependent on the CPU capability and the kernel configuration. > The limit can be retrieved using KVM_CAP_ARM_VM_IPA_SIZE of the > KVM_CHECK_EXTENSION ioctl() at run-time. > > Creation of the VM will fail if the requested IPA size (whether it is > implicit or explicit) is unsupported on the host. https://docs.kernel.org/virt/kvm/api.html#kvm-create-vm So if Host_IPA_Limit < 40, specifying 0 as the type will fail. This actually confused libvirt, which uses "none" machine model to probe the KVM availability, on M2 MacBook Air. Fix this by using Host_IPA_Limit as the default type when KVM_CAP_ARM_VM_IPA_SIZE is available. Cc: [email protected] Signed-off-by: Akihiko Odaki <[email protected]> Message-id: [email protected] Reviewed-by: Peter Maydell <[email protected]> Signed-off-by: Peter Maydell <[email protected]> (cherry picked from commit 1ab445a) Signed-off-by: Michael Tokarev <[email protected]>
A typo, noted in the bug report, resulting in an incorrect write offset. Cc: [email protected] Fixes: 7390e0e ("target/arm: Implement SME LD1, ST1") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1833 Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]> (cherry picked from commit 4b3520f) Signed-off-by: Michael Tokarev <[email protected]>
Typo applied byte-wise shift instead of double-word shift. Cc: [email protected] Fixes: 631e565 ("target/arm: Create gen_gvec_[us]sra") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1737 Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: Peter Maydell <[email protected]> (cherry picked from commit cd1e4db) Signed-off-by: Michael Tokarev <[email protected]>
In early 2021 (see commit 2ad7843 "docs: update README to use GitLab repo URLs") almost all of the code base was converted to point to GitLab instead of git.qemu.org. During 2023, git.qemu.org switched from a git mirror to a http redirect to GitLab (see [1]). Update the LICENSE URL to match its previous content, displaying the file raw content similarly to gitweb 'blob_plain' format ([2]). [1] https://lore.kernel.org/qemu-devel/CABgObfZu3mFc8tM20K-yXdt7F-7eV-uKZN4sKDarSeu7DYoRbA@mail.gmail.com/ [2] https://git-scm.com/docs/gitweb#Documentation/gitweb.txt-blobplain Reviewed-by: Daniel P. Berrangé <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Reviewed-by: Stefan Hajnoczi <[email protected]> Signed-off-by: Stefan Hajnoczi <[email protected]> Message-ID: <[email protected]> (cherry picked from commit 09a3fff) Signed-off-by: Michael Tokarev <[email protected]>
Acked-by: Alex Bennée <[email protected]> Suggested-by: Alex Bennée <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 86e4f93) Signed-off-by: Michael Tokarev <[email protected]>
We can fail the blk_insert_bs() at init_blk_migration(), leaving the BlkMigDevState without a dirty_bitmap and BlockDriverState. Account for the possibly missing elements when doing cleanup. Fix the following crashes: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 359 BlockDriverState *bs = bitmap->bs; #0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at ../block/dirty-bitmap.c:359 qemu#1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371 qemu#2 0x0000555555bbad98 in block_migration_cleanup_bmds () at ../migration/block.c:681 Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) { #0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073 qemu#1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at ../block.c:7095 qemu#2 0x0000555555bbae13 in block_migration_cleanup_bmds () at ../migration/block.c:690 Signed-off-by: Fabiano Rosas <[email protected]> Message-id: [email protected] Signed-off-by: Stefan Hajnoczi <[email protected]> (cherry picked from commit f187609) Signed-off-by: Michael Tokarev <[email protected]>
This is a mandatory feature for Armv8.1 architectures but we don't state the feature clearly in our emulation list. Also include FEAT_CRC32 comment in aarch64_max_tcg_initfn for ease of grepping. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Alex Bennée <[email protected]> Message-id: [email protected] Cc: [email protected] Message-Id: <[email protected]> [PMM: pluralize 'instructions' in docs] Signed-off-by: Peter Maydell <[email protected]> (cherry picked from commit 9e771a2) Signed-off-by: Michael Tokarev <[email protected]>
PIE executables are usually linked at offset 0 and are relocated somewhere during load. The hiaddr needs to be adjusted to keep the brk next to the executable. Cc: [email protected] Fixes: 1f356e8 ("linux-user: Adjust initial brk when interpreter is close to executable") Tested-by: Helge Deller <[email protected]> Reviewed-by: Ilya Leoshkevich <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit aec338d) Signed-off-by: Michael Tokarev <[email protected]>
Otherwise tcg_handle_interrupt() triggers an assertion failure: qemu#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:83 qemu#6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at ../accel/tcg/tcg-accel-ops.c:81 qemu#7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>, irq=<optimized out>, level=1) at ../hw/i386/x86.c:555 qemu#8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1) at ../hw/i386/x86.c:611 qemu#9 0x00007fffa42bde14 in code_gen_buffer () qemu#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0, itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at ../accel/tcg/cpu-exec.c:457 Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1808 Reported-by: NyanCatTW1 <https://gitlab.com/a0939712328> Co-developed-by: Richard Henderson <[email protected]>' Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit c1f27a0) Signed-off-by: Michael Tokarev <[email protected]>
Fixes: 142ca62 ("ui: add a D-Bus display backend") Fixes: de9f844 ("ui/dbus: Expose a touch device interface") Signed-off-by: Bilal Elmoussaoui <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Message-Id: <[email protected]> (cherry picked from commit cb6ccdc) Signed-off-by: Michael Tokarev <[email protected]>
Failing to reset the of_instance_last makes ihandle allocation continue to increase, which causes record-replay replay fail to match the recorded trace. Not resetting claimed_base makes VOF eventually run out of memory after some resets. Cc: Alexey Kardashevskiy <[email protected]> Fixes: fc8c745 ("spapr: Implement Open Firmware client interface") Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 7b8589d) Signed-off-by: Michael Tokarev <[email protected]>
ppce500_reset_device_tree is registered for system reset, but after c4b0753 this function rerandomizes rng-seed via qemu_guest_getrandom_nofail. And when loading a snapshot, it tries to read EVENT_RANDOM that doesn't exist, so we have an error: qemu-system-ppc: Missing random event in the replay log To fix this, use qemu_register_reset_nosnapshotload instead of qemu_register_reset. Reported-by: Vitaly Cheptsov <[email protected]> Fixes: c4b0753 ("hw/ppc: pass random seed to fdt ") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1634 Signed-off-by: Maksim Kostin <[email protected]> Reviewed-by: Nicholas Piggin <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 6ec65b6) Signed-off-by: Michael Tokarev <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1779 Signed-off-by: Richard Henderson <[email protected]> Reviewed-by: Nicholas Piggin <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit af03aeb) Signed-off-by: Michael Tokarev <[email protected]>
LQ, STQ have the same register-pair ordering as LQARX/STQARX., which is the even (lower) register contains the most significant bits. This is not implemented correctly for big-endian. do_ldst_quad() has variables low_addr_gpr and high_addr_gpr which is confusing because they are low and high addresses, whereas LQARX/STQARX. and most such things use the low and high values for lo/hi variables. The conversion to native 128-bit memory access functions missed this strangeness. Fix this by changing the if condition, and change the variable names to hi/lo to match convention. Cc: [email protected] Reported-by: Ivan Warren <[email protected]> Fixes: 57b38ff ("target/ppc: Use tcg_gen_qemu_{ld,st}_i128 for LQARX, LQ, STQ") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1836 Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 7182093) Signed-off-by: Michael Tokarev <[email protected]>
Currently, the first time sending an unsupported command (e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion. Sending the unsupported command again, will correctly have ERR_STAT set. When ide_cmd_permitted() returns false, it calls ide_abort_command(). ide_abort_command() first calls ide_transfer_stop(), which will call ide_transfer_halt() and ide_cmd_done(), after that ide_abort_command() sets ERR_STAT in status. ide_cmd_done() for AHCI will call ahci_write_fis_d2h() which writes the current status in the FIS, and raises an IRQ. (The status here will not have ERR_STAT set!). Thus, we cannot call ide_transfer_stop() before setting ERR_STAT, as ide_transfer_stop() will result in the FIS being written and an IRQ being raised. The reason why it works the second time, is that ERR_STAT will still be set from the previous command, so when writing the FIS, the completion will correctly have ERR_STAT set. Set ERR_STAT before writing the FIS (calling cmd_done), so that we will raise an error IRQ correctly when receiving an unsupported command. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit c3461c6) Signed-off-by: Michael Tokarev <[email protected]>
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is described in SATA 3.5a Gold: 11.15 FPDMA QUEUED command protocol DFPDMAQ2: ClearInterfaceBsy "Transmit Register Device to Host FIS with the BSY bit cleared to zero and the DRQ bit cleared to zero and Interrupt bit cleared to zero to mark interface ready for the next command." PxCI is currently cleared by handle_cmd(), but we don't write the D2H FIS to the FIS Receive Area that actually caused PxCI to be cleared. Similar to how ahci_pio_transfer() calls ahci_write_fis_pio() with an additional parameter to write a PIO Setup FIS without raising an IRQ, add a parameter to ahci_write_fis_d2h() so that ahci_write_fis_d2h() also can write the FIS to the FIS Receive Area without raising an IRQ. Change process_ncq_command() to call ahci_write_fis_d2h() without raising an IRQ (similar to ahci_pio_transfer()), such that the FIS Receive Area is in sync with the PxTFD shadow register. E.g. Linux reads status and error fields from the FIS Receive Area directly, so it is wise to keep the FIS Receive Area and the PxTFD shadow register in sync. Signed-off-by: Niklas Cassel <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit 2967dc8) Signed-off-by: Michael Tokarev <[email protected]>
The AHCI spec states that: For NCQ, PxCI is cleared on command queued successfully. For non-NCQ, PxCI is cleared on command completed successfully. (A non-NCQ command that completes with error does not clear PxCI.) The current QEMU implementation either clears PxCI in check_cmd(), or in ahci_cmd_done(). check_cmd() will clear PxCI for a command if handle_cmd() returns 0. handle_cmd() will return -1 if BUSY or DRQ is set. The QEMU implementation for NCQ commands will currently not set BUSY or DRQ, so they will always have PxCI cleared by handle_cmd(). ahci_cmd_done() will never even get called for NCQ commands. Non-NCQ commands are executed by ide_bus_exec_cmd(). Non-NCQ commands in QEMU are implemented either in a sync or in an async way. For non-NCQ commands implemented in a sync way, the command handler will return true, and when ide_bus_exec_cmd() sees that a command handler returns true, it will call ide_cmd_done() (which will call ahci_cmd_done()). For a command implemented in a sync way, ahci_cmd_done() will do nothing (since busy_slot is not set). Instead, after ide_bus_exec_cmd() has finished, check_cmd() will clear PxCI for these commands. For non-NCQ commands implemented in an async way (using either aiocb or pio_aiocb), the command handler will return false, ide_bus_exec_cmd() will not call ide_cmd_done(), instead it is expected that the async callback function will call ide_cmd_done() once the async command is done. handle_cmd() will set busy_slot, if and only if BUSY or DRQ is set, and this is checked _after_ ide_bus_exec_cmd() has returned. handle_cmd() will return -1, so check_cmd() will not clear PxCI. When the async callback calls ide_cmd_done() (which will call ahci_cmd_done()), it will see that busy_slot is set, and ahci_cmd_done() will clear PxCI. This seems racy, since busy_slot is set _after_ ide_bus_exec_cmd() has returned. The callback might come before busy_slot gets set. And it is quite confusing that ahci_cmd_done() will be called for all non-NCQ commands when the command is done, but will only clear PxCI in certain cases, even though it will always write a D2H FIS and raise an IRQ. Even worse, in the case where ahci_cmd_done() does not clear PxCI, it still raises an IRQ. Host software might thus read an old PxCI value, since PxCI is cleared (by check_cmd()) after the IRQ has been raised. Try to simplify this by always setting busy_slot for non-NCQ commands, such that ahci_cmd_done() will always be responsible for clearing PxCI for non-NCQ commands. For NCQ commands, clear PxCI when we receive the D2H FIS, but before raising the IRQ, see AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI. Signed-off-by: Niklas Cassel <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit e2a5d9b) Signed-off-by: Michael Tokarev <[email protected]>
According to AHCI 1.3.1 definition of PxSACT: This field is cleared when PxCMD.ST is written from a '1' to a '0' by software. This field is not cleared by a COMRESET or a software reset. According to AHCI 1.3.1 definition of PxCI: This field is also cleared when PxCMD.ST is written from a '1' to a '0' by software. Clearing PxCMD.ST is part of the error recovery procedure, see AHCI 1.3.1, section "6.2 Error Recovery". If we don't clear PxCI on error recovery, the previous command will incorrectly still be marked as pending after error recovery. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit d73b84d) Signed-off-by: Michael Tokarev <[email protected]>
For NCQ, PxCI is cleared on command queued successfully. For non-NCQ, PxCI is cleared on command completed successfully. Successfully means ERR_STAT, BUSY and DRQ are all cleared. A command that has ERR_STAT set, does not get to clear PxCI. See AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI, and 5.3.16.5 ERR:FatalTaskfile. In the case of non-NCQ commands, not clearing PxCI is needed in order for host software to be able to see which command slot that failed. Signed-off-by: Niklas Cassel <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit 1a16ce6) Signed-off-by: Michael Tokarev <[email protected]>
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1, 5.3.13.1 SDB:Entry. If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or not. Thus, we should never raise a normal IRQ after having sent an error IRQ. It is valid to signal successfully completed commands as finished in the same SDB FIS that generates the error IRQ. The important thing is that commands that did not complete successfully (e.g. commands that were aborted, do not get the finished bit set). Before this commit, there was never a TFES IRQ raised on NCQ error. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit 7e85cb0) Signed-off-by: Michael Tokarev <[email protected]>
When encountering an NCQ error, you should not write the NCQ tag to the SError register. This is completely wrong. The SError register has a clear definition, where each bit represents a different error, see PxSERR definition in AHCI 1.3.1. If we write a random value (like the NCQ tag) in SError, e.g. Linux will read SError, and will trigger arbitrary error handling depending on the NCQ tag that happened to be executing. In case of success, ncq_cb() will call ncq_finish(). In case of error, ncq_cb() will call ncq_err() (which will clear ncq_tfs->used), and then call ncq_finish(), thus using ncq_tfs->used is sufficient to tell if finished should get set or not. Signed-off-by: Niklas Cassel <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-id: [email protected] Signed-off-by: John Snow <[email protected]> (cherry picked from commit 9f89423) Signed-off-by: Michael Tokarev <[email protected]>
Fixed inconsistency between the regisiter bit field definition header file and the ast2600 datasheet. The reg name is I2CD1C:Pool Buffer Control Register in old register mode and I2CC0C: Master/Slave Pool Buffer Control Register in new register mode. They share bit field [12:8]:Transmit Data Byte Count and bit field [29:24]:Actual Received Pool Buffer Size according to the datasheet. According to the ast2600 datasheet,the actual Tx count is Transmit Data Byte Count plus 1, and the max Rx size is Receive Pool Buffer Size plus 1, both in Pool Buffer Control Register. The version before forgot to plus 1, and mistake Rx count for Rx size. Signed-off-by: Hang Yu <[email protected]> Fixes: 3be3d6c ("aspeed: i2c: Migrate to registerfields API") Reviewed-by: Cédric Le Goater <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 97b8aa5) Signed-off-by: Michael Tokarev <[email protected]>
According to the ast2600 datasheet and the linux aspeed i2c driver, the TXBUF transmission start position should be TXBUF[0] instead of TXBUF[1],so the arg pool_start is useless,and the address is not included in TXBUF.So even if Tx Count equals zero,there is at least 1 byte data needs to be transmitted,and M_TX_CMD should not be cleared at this condition.The driver url is: https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/drivers/i2c/busses/i2c-ast2600.c Signed-off-by: Hang Yu <[email protected]> Fixes: 6054fc7 ("aspeed/i2c: Add support for pool buffer transfers") Reviewed-by: Cédric Le Goater <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 961faf3) Signed-off-by: Michael Tokarev <[email protected]>
…ions The current description says that these options will create a device on the IDE bus, which is only true on x86. So rephrase these sentences a little bit to speak of "default bus" instead. Signed-off-by: Thomas Huth <[email protected]> Reviewed-by: Alex Bennée <[email protected]> Signed-off-by: Michael Tokarev <[email protected]> (cherry picked from commit bcd8e24) Signed-off-by: Michael Tokarev <[email protected]>
Without this we can get see loops through cpu_io_recompile, in which the cpu makes no progress. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 200c1f9) Signed-off-by: Michael Tokarev <[email protected]>
Require i/o as the last insn of a TranslationBlock always, not only with icount. This is required for i/o that alters the address space, such as a pci config space write. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1866 Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 18a536f) Signed-off-by: Michael Tokarev <[email protected]>
we would crash if width was 0 for these insns, as tcg_gen_deposit() is undefined for that case. For TriCore, width = 0 is a mov from the src reg to the dst reg, so we special case this here. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Richard Henderson <[email protected]> Signed-off-by: Bastian Koppelmann <[email protected]> Message-ID: <[email protected]> (cherry picked from commit 23fa6f5) Signed-off-by: Michael Tokarev <[email protected]>
Our linker script for optionroms specifies only the placement of the
.text section, leaving the linker free to place the remaining sections
at arbitrary places in the file.
Since at least binutils 2.39, the .note.gnu.build-id section is now
being placed at the start of the file, which causes label addresses to
be shifted. For linuxboot_dma.bin that means that the PnP header
(among others) will not be found when determining the type of ROM at
optionrom_setup():
(0x1c is the label _pnph, where the magic "PnP" is)
$ xxd /usr/share/qemu/linuxboot_dma.bin | grep "PnP"
00000010: 0000 0000 0000 0000 0000 1c00 2450 6e50 ............$PnP
$ xxd pc-bios/optionrom/linuxboot_dma.bin | grep "PnP"
00000010: 0000 0000 0000 0000 0000 4c00 2450 6e50 ............$PnP
^bad
Using a freshly built linuxboot_dma.bin ROM results in a broken boot:
SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org)
Booting from Hard Disk...
Boot failed: could not read the boot disk
Booting from Floppy...
Boot failed: could not read the boot disk
No bootable device.
We're not using the build-id section, so pass the --build-id=none
option to the linker to remove it entirely.
Note: In theory, this same issue could happen with any other
section. The ideal solution would be to have all unused sections
discarded in the linker script. However that would be a larger change,
specially for the pvh rom which uses the .bss and COMMON sections so
I'm addressing only the immediate issue here.
Reported-by: Vasiliy Ulyanov <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 35ed01b)
Signed-off-by: Michael Tokarev <[email protected]>
(mjt: remove unrelated stable@vger)
The call to esp_dma_enable() was being made with the SYSBUS_ESP type instead of the ESP type. This meant that when GPIO 1 was being used to trigger a DMA request from an external DMA controller, the setting of ESPState's dma_enabled field would clobber unknown memory whilst the dma_cb callback pointer would typically return NULL so the DMA request would never start. Signed-off-by: Mark Cave-Ayland <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit b86dc5c) Signed-off-by: Michael Tokarev <[email protected]>
In the case where a SCSI layer transfer is incorrectly terminated, it is possible for a TI command to cause a SCSI buffer overflow due to the expected transfer data length being less than the available data in the FIFO. When this occurs the unsigned async_len variable underflows and becomes a large offset which writes past the end of the allocated SCSI buffer. Restrict the non-DMA transfer length to be the smallest of the expected transfer length and the available FIFO data to ensure that it is no longer possible for the SCSI buffer overflow to occur. Signed-off-by: Mark Cave-Ayland <[email protected]> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1810 Reviewed-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit 77668e4) Signed-off-by: Michael Tokarev <[email protected]>
Otherwise when a FORMAT UNIT command is issued, the SCSI layer can become confused because it can find itself in the situation where it thinks there is still data to be transferred which can cause the next emulated SCSI command to fail. Signed-off-by: Mark Cave-Ayland <[email protected]> Fixes: 6ab7176 ("scsi-disk: add FORMAT UNIT command") Tested-by: Thomas Huth <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit be2b619) Signed-off-by: Michael Tokarev <[email protected]>
…er warnings Update the berkeley-testfloat-3 wrap to include a patch provided by Olaf Hering. This fixes a problem with "control reaches end of non-void function [-Werror=return-type]" compiler warning/errors that are now enabled by default in certain versions of GCC. Reported-by: Olaf Hering <[email protected]> Message-Id: <[email protected]> Signed-off-by: Thomas Huth <[email protected]> (cherry picked from commit c01196b) Signed-off-by: Michael Tokarev <[email protected]>
CVTPS2PD only loads a half-register for memory, like CVTPH2PS. It can reuse the "ph" packed half-precision size to load a half-register, but rename it to "xh" because it is now a variation of "x" (it is not used only for half-precision values). Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit a48b269) Signed-off-by: Michael Tokarev <[email protected]>
CVTPS2PD only loads a half-register for memory, unlike the other operations under 0x0F 0x5A. "Unpack" the group into separate emission functions instead of using gen_unary_fp_sse. Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit abd4188) Signed-off-by: Michael Tokarev <[email protected]>
In all likelihood, the compiler with lto doesn't see the function being used, from assembly macro __try1. Help it by marking the function has being used. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1904 Fixes: commit d89f30b ("win32: wrap socket close() with an exception handler") Signed-off-by: Marc-André Lureau <[email protected]> Reviewed-by: Thomas Huth <[email protected]> (cherry picked from commit 75b773d) Signed-off-by: Michael Tokarev <[email protected]> (mjt: trivial context fixup in include/qemu/compiler.h)
The fw_cfg DMA write callback in ramfb prepares a new display surface in
QEMU; this new surface is put to use ("swapped in") upon the next display
update. At that time, the old surface (if any) is released.
If the guest triggers the fw_cfg DMA write callback at least twice between
two adjacent display updates, then the second callback (and further such
callbacks) will leak the previously prepared (but not yet swapped in)
display surface.
The issue can be shown by:
(1) starting QEMU with "-trace displaysurface_free", and
(2) running the following program in the guest UEFI shell:
> #include <Library/ShellCEntryLib.h> // ShellAppMain()
> #include <Library/UefiBootServicesTableLib.h> // gBS
> #include <Protocol/GraphicsOutput.h> // EFI_GRAPHICS_OUTPUT_PROTOCOL
>
> INTN
> EFIAPI
> ShellAppMain (
> IN UINTN Argc,
> IN CHAR16 **Argv
> )
> {
> EFI_STATUS Status;
> VOID *Interface;
> EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop;
> UINT32 Mode;
>
> Status = gBS->LocateProtocol (
> &gEfiGraphicsOutputProtocolGuid,
> NULL,
> &Interface
> );
> if (EFI_ERROR (Status)) {
> return 1;
> }
>
> Gop = Interface;
>
> Mode = 1;
> for ( ; ;) {
> Status = Gop->SetMode (Gop, Mode);
> if (EFI_ERROR (Status)) {
> break;
> }
>
> Mode = 1 - Mode;
> }
>
> return 1;
> }
The symptom is then that:
- only one trace message appears periodically,
- the time between adjacent messages keeps increasing -- implying that
some list structure (containing the leaked resources) keeps growing,
- the "surface" pointer is ever different.
> [email protected]:displaysurface_free surface=0x7f2fcc09a7c0
> [email protected]:displaysurface_free surface=0x7f2fcc9dac10
> [email protected]:displaysurface_free surface=0x7f2fcc441dd0
> [email protected]:displaysurface_free surface=0x7f2fcc0363d0
> [email protected]:displaysurface_free surface=0x7f2fcc413a80
> [email protected]:displaysurface_free surface=0x7f2fcc09cd00
> [email protected]:displaysurface_free surface=0x7f2fcc1395f0
> [email protected]:displaysurface_free surface=0x7f2fcc1cae50
> [email protected]:displaysurface_free surface=0x7f2fcc42fc50
> [email protected]:displaysurface_free surface=0x7f2fcc45dcc0
> [email protected]:displaysurface_free surface=0x7f2fcc70b9d0
> [email protected]:displaysurface_free surface=0x7f2fcc82acc0
> [email protected]:displaysurface_free surface=0x7f2fcc369c00
> [email protected]:displaysurface_free surface=0x7f2fcc32b910
> [email protected]:displaysurface_free surface=0x7f2fcc0d5a20
> [email protected]:displaysurface_free surface=0x7f2fcc086c40
> [email protected]:displaysurface_free surface=0x7f2fccc72020
> [email protected]:displaysurface_free surface=0x7f2fcc185160
> [email protected]:displaysurface_free surface=0x7f2fcc23a7e0
> [email protected]:displaysurface_free surface=0x7f2fcc3ec870
> [email protected]:displaysurface_free surface=0x7f2fcc634960
> [email protected]:displaysurface_free surface=0x7f2fcc26b140
> [email protected]:displaysurface_free surface=0x7f2fcc321700
> [email protected]:displaysurface_free surface=0x7f2fccaad100
We figured this wasn't a CVE-worthy problem, as only small amounts of
memory were leaked (the framebuffer itself is mapped from guest RAM, QEMU
only allocates administrative structures), plus libvirt restricts QEMU
memory footprint anyway, thus the guest can only DoS itself.
Plug the leak, by releasing the last prepared (not yet swapped in) display
surface, if any, in the fw_cfg DMA write callback.
Regarding the "reproducer", with the fix in place, the log is flooded with
trace messages (one per fw_cfg write), *and* the trace message alternates
between just two "surface" pointer values (i.e., nothing is leaked, the
allocator flip-flops between two objects in effect).
This issue appears to date back to the introducion of ramfb (995b301,
"hw/display: add ramfb, a simple boot framebuffer living in guest ram",
2018-06-18).
Cc: Gerd Hoffmann <[email protected]> (maintainer:ramfb)
Cc: [email protected]
Fixes: 995b301
Signed-off-by: Laszlo Ersek <[email protected]>
Acked-by: Laszlo Ersek <[email protected]>
Reviewed-by: Gerd Hoffmann <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e0288a7)
Signed-off-by: Michael Tokarev <[email protected]>
…nnected When starting a guest via libvirt with "virsh start --console ...", the first second of the console output is missing. This is especially annoying on s390x that only has a text console by default and no graphical output - if the bios fails to boot here, the information about what went wrong is completely lost. One part of the problem (there is also some things to be done on the libvirt side) is that QEMU only checks with a 1 second timer whether the other side of the pty is already connected, so the first second of the console output is always lost. This likely used to work better in the past, since the code once checked for a re-connection during write, but this has been removed in commit f8278c7 ("char-pty: remove the check for connection on write") to avoid some locking. To ease the situation here at least a little bit, let's check with g_poll() whether we could send out the data anyway, even if the connection has not been marked as "connected" yet. The file descriptor is marked as non-blocking anyway since commit fac6688 ("Do not hang on full PTY"), so this should not cause any trouble if the other side is not ready for receiving yet. With this patch applied, I can now successfully see the bios output of a s390x guest when running it with "virsh start --console" (with a patched version of virsh that fixes the remaining issues there, too). Reported-by: Marc Hartmayer <[email protected]> Signed-off-by: Thomas Huth <[email protected]> Reviewed-by: Daniel P. Berrangé <[email protected]> Message-Id: <[email protected]> (cherry picked from commit 4f7689f) Signed-off-by: Michael Tokarev <[email protected]>
Use abi_ullong not uint64_t so that the alignment of the field and therefore the layout of the struct is correct. Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Richard Henderson <[email protected]> (cherry picked from commit 33bc4fa) Signed-off-by: Michael Tokarev <[email protected]>
Not zeroing it causes a SIGSEGV if the live migration is cancelled, at net device restart. This is caused because CVQ tries to reuse the iova_tree that is present in the first vhost_vdpa device at the end of vhost_vdpa_net_cvq_start. As a consequence, it tries to access an iova_tree that has been already free. Fixes: 00ef422 ("vdpa net: move iova tree creation from init to start") Reported-by: Yanhui Ma <[email protected]> Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Acked-by: Jason Wang <[email protected]> Tested-by: Lei Yang <[email protected]> Reviewed-by: Si-Wei Liu <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> (cherry picked from commit 0a7a164) Signed-off-by: Michael Tokarev <[email protected]>
It incorrectly prints "error setting features", probably because a copy paste miss. Fixes: 152128d ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by: Peter Maydell <[email protected]> Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Tested-by: Lei Yang <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> (cherry picked from commit cbc9ae8) Signed-off-by: Michael Tokarev <[email protected]>
Otherwise it continues the CVQ isolation probing. Fixes: 152128d ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Reported-by: Peter Maydell <[email protected]> Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Tested-by: Lei Yang <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> (cherry picked from commit f108588) Signed-off-by: Michael Tokarev <[email protected]>
This patch solves a few issues. The most obvious is that the feature set was done previous to ACKNOWLEDGE | DRIVER status bit set. Current vdpa devices are permissive with this, but it is better to follow the standard. Fixes: 152128d ("vdpa: move CVQ isolation check to net_init_vhost_vdpa") Signed-off-by: Eugenio Pérez <[email protected]> Message-Id: <[email protected]> Tested-by: Lei Yang <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> (cherry picked from commit 845ec38) Signed-off-by: Michael Tokarev <[email protected]>
An MSI from I/O APIC may not exactly equal to APIC_DEFAULT_ADDRESS. In fact, Windows 17763.3650 configures I/O APIC to set the dest_mode bit. Cover the range assigned to APIC. Fixes: 577c470 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Akihiko Odaki <[email protected]> Message-Id: <[email protected]> Reviewed-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> (cherry picked from commit 0114c45) Signed-off-by: Michael Tokarev <[email protected]>
The below referenced commit renames scanout_width/height to backing_width/height, but also promotes these fields in various portions of the egl interface. Meanwhile vfio dmabuf support has never used the previous scanout fields and is therefore missed in the update. This results in a black screen when transitioning from ramfb to dmabuf display when using Intel vGPU with these features. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1891 Link: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg02726.html Fixes: 9ac06df ("virtio-gpu-udmabuf: correct naming of QemuDmaBuf size properties") Signed-off-by: Alex Williamson <[email protected]> Tested-by: Cédric Le Goater <[email protected]> Signed-off-by: Cédric Le Goater <[email protected]> (cherry picked from commit 931150e) Signed-off-by: Michael Tokarev <[email protected]>
Commit 59bde21 ("util/log: do not close and reopen log files when flags are turned off") prevented switching away from stderr on a subsequent invocation of qemu_set_log_internal(). This prevented switching away from stderr with the 'logfile' monitor command as well as an invocation like > ./qemu-system-x86_64 -trace 'qemu_mutex_lock,file=log' from opening the specified log file. Fixes: 59bde21 ("util/log: do not close and reopen log files when flags are turned off") Signed-off-by: Fiona Ebner <[email protected]> Message-ID: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> (cherry picked from commit f05142d) Signed-off-by: Michael Tokarev <[email protected]>
QEMU will crash if anyone tries to set tls-authz (which is a type StrOrNull) with 'null' value. Fix it in the easy way by converting it to qstring just like the other two tls parameters. Cc: [email protected] # v4.0+ Fixes: d2f1d29 ("migration: add support for a "tls-authz" migration parameter") Reviewed-by: Daniel P. Berrangé <[email protected]> Reviewed-by: Fabiano Rosas <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Reviewed-by: Juan Quintela <[email protected]> Signed-off-by: Peter Xu <[email protected]> Signed-off-by: Juan Quintela <[email protected]> Message-ID: <[email protected]> (cherry picked from commit 86dec71) Signed-off-by: Michael Tokarev <[email protected]>
Reset the current sample counter when writing the Channel Sample Count Register. The Linux ens1370 driver and the AROS sb128 driver expect the current sample counter counts down from sample count to 0 after a write to the Channel Sample Count Register. Currently the current sample counter starts from 0 after a reset or the last count when the counter was stopped. The current sample counter is used to raise an interrupt whenever a complete buffer was transferred. When the counter starts with a value lower than the reload value, the interrupt triggeres before the buffer was completly transferred. This may lead to corrupted audio streams. Tested-by: Rene Engel <[email protected]> Signed-off-by: Volker Rümelin <[email protected]> Reviewed-by: Marc-André Lureau <[email protected]> Tested-by: BALATON Zoltan <[email protected]> Message-Id: <[email protected]> (cherry picked from commit 00e3b29) Signed-off-by: Michael Tokarev <[email protected]>
python3 may not be the expected python version. Use PYTHON to invoke python. Fixes: 22e1153 ("edk2: replace build scripts") Signed-off-by: Olaf Hering <[email protected]> Signed-off-by: Michael Tokarev <[email protected]> (cherry picked from commit 17b8d8a)
Fix the inverted order of pmpaddr13 and pmpaddr14 in csr_name(). Signed-off-by: Alvin Chang <[email protected]> Reviewed-by: Alistair Francis <[email protected]> Message-ID: <[email protected]> Signed-off-by: Alistair Francis <[email protected]> (cherry picked from commit cffa995) Signed-off-by: Michael Tokarev <[email protected]>
The operator (fwmacc16) of vfwmaccbf16.vf helper function should be replaced by fwmaccbf16. Fixes: adf772b ("target/riscv: Add support for Zvfbfwma extension") Signed-off-by: Max Chou <[email protected]> Reviewed-by: LIU Zhiwei <[email protected]> Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Message-ID: <[email protected]> Signed-off-by: Alistair Francis <[email protected]> (cherry picked from commit 837570c) Signed-off-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
|
Thank you for your interest in the QEMU project. This repository is a read-only mirror of the project's repostories hosted QEMU welcomes contributions of code (either fixing bugs or adding new |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.