Skip to content
Snippets Groups Projects
  1. Feb 09, 2024
  2. Jan 29, 2024
  3. Jan 27, 2024
    • Peter Maydell's avatar
      target/arm: Fix incorrect aa64_tidcp1 feature check · 45b3ce5e
      Peter Maydell authored
      A typo in the implementation of isar_feature_aa64_tidcp1() means we
      were checking the field in the wrong ID register, so we might have
      provided the feature on CPUs that don't have it and not provided
      it on CPUs that should have it. Correct this bug.
      
      Cc: qemu-stable@nongnu.org
      Fixes: 9cd0c0de "target/arm: Implement FEAT_TIDCP1"
      Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2120
      
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Message-id: 20240123160333.958841-1-peter.maydell@linaro.org
      (cherry picked from commit ee0a2e3c9d2991a11c13ffadb15e4d0add43c257)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      45b3ce5e
    • Peter Maydell's avatar
      target/arm: Fix A64 scalar SQSHRN and SQRSHRN · 570e6244
      Peter Maydell authored
      In commit 1b7bc9b5 we changed handle_vec_simd_sqshrn() so
      that instead of starting with a 0 value and depositing in each new
      element from the narrowing operation, it instead started with the raw
      result of the narrowing operation of the first element.
      
      This is fine in the vector case, because the deposit operations for
      the second and subsequent elements will always overwrite any higher
      bits that might have been in the first element's result value in
      tcg_rd.  However in the scalar case we only go through this loop
      once.  The effect is that for a signed narrowing operation, if the
      result is negative then we will now return a value where the bits
      above the first element are incorrectly 1 (because the narrowfn
      returns a sign-extended result, not one that is truncated to the
      element size).
      
      Fix this by using an extract operation to get exactly the correct
      bits of the output of the narrowfn for element 1, instead of a
      plain move.
      
      Cc: qemu-stable@nongnu.org
      Fixes: 1b7bc9b5 ("target/arm: Avoid tcg_const_ptr in handle_vec_simd_sqshrn")
      Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089
      
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Message-id: 20240123153416.877308-1-peter.maydell@linaro.org
      (cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      570e6244
    • Max Filippov's avatar
      target/xtensa: fix OOB TLB entry access · 553e53b4
      Max Filippov authored
      
      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: b67ea0cd ("target-xtensa: implement memory protection options")
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Reviewed-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      (cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      553e53b4
  4. Jan 26, 2024
    • Daniel P. Berrangé's avatar
      qtest: bump aspeed_smc-test timeout to 6 minutes · ce34d02f
      Daniel P. Berrangé authored
      
      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: default avatarDaniel P. Berrangé <berrange@redhat.com>
      [thuth: Increase the timeout to 6 minutes for very loaded systems]
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Message-Id: <20231215070357.10888-11-thuth@redhat.com>
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      (cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      (Mjt: context fixup in tests/qtest/meson.build)
      ce34d02f
    • Stefan Hajnoczi's avatar
      monitor: only run coroutine commands in qemu_aio_context · f389309d
      Stefan Hajnoczi authored
      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: 7bed8995 ("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: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20240118144823.1497953-4-stefanha@redhat.com>
      Reviewed-by: default avatarKevin Wolf <kwolf@redhat.com>
      Tested-by: default avatarFiona Ebner <f.ebner@proxmox.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      (cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      f389309d
    • Stefan Hajnoczi's avatar
      iotests: port 141 to Python for reliable QMP testing · 823892d1
      Stefan Hajnoczi authored
      
      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: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20240118144823.1497953-3-stefanha@redhat.com>
      Reviewed-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      (cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      823892d1
    • Stefan Hajnoczi's avatar
      iotests: add filter_qmp_generated_node_ids() · d7a64c45
      Stefan Hajnoczi authored
      
      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: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20240118144823.1497953-2-stefanha@redhat.com>
      Reviewed-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      (cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      d7a64c45
    • Ari Sundholm's avatar
      block/blklogwrites: Fix a bug when logging "write zeroes" operations. · cf709665
      Ari Sundholm authored
      
      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: default avatarAri Sundholm <ari@tuxera.com>
      Cc: qemu-stable@nongnu.org
      Message-ID: <20240109184646.1128475-1-megari@gmx.com>
      Reviewed-by: default avatarKevin Wolf <kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      (cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      cf709665
    • Jason Wang's avatar
      virtio-net: correctly copy vnet header when flushing TX · 939a0957
      Jason Wang authored
      
      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: default avatarXiao 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: e22f0603 ("virtio-net: reference implementation of hash report")
      Reviewed-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      (cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      939a0957
  5. Jan 25, 2024
    • Joseph Burt's avatar
      tcg/arm: Fix SIGILL in tcg_out_qemu_st_direct · 6f6492ab
      Joseph Burt authored
      
      When tcg_out_qemu_st_{index,direct} were merged, the direct case for
      MO_64 was omitted, causing qemu_st_i64 to be encoded as 0xffffffff due
      to underflow when adding h.base and h.index.
      
      Fixes: 1df6d611 ("tcg/arm: Introduce HostAddress")
      Signed-off-by: default avatarJoseph Burt <caseorum@gmail.com>
      Message-Id: <20240121211439.100829-1-caseorum@gmail.com>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      (cherry picked from commit 9f6523e8e4689cafdbed7c10b7cf7c775b5a607b)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      6f6492ab
    • Richard Henderson's avatar
      linux-user/riscv: Adjust vdso signal frame cfa offsets · 1e0f028d
      Richard Henderson authored
      
      A typo in sizeof_reg put the registers at the wrong offset.
      
      Simplify the expressions to use positive addresses from the
      start of uc_mcontext instead of negative addresses from the
      end of uc_mcontext.
      
      Reported-by: default avatarVineet Gupta <vineetg@rivosinc.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@linaro.org>
      Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      (cherry picked from commit 1b21fe27e75a59bfe2513f5abcc6a18cfc35cfc8)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      1e0f028d
    • Robbin Ehn's avatar
      linux-user: Fixed cpu restore with pc 0 on SIGBUS · 8bdd3abc
      Robbin Ehn authored
      
      Commit f4e11681 (linux-user: Split out host_sig{segv,bus}_handler)
      introduced a bug, when returning from host_sigbus_handler the PC is
      never set. Thus cpu_loop_exit_restore is called with a zero PC and
      we immediate get a SIGSEGV.
      
      Signed-off-by: default avatarRobbin Ehn <rehn@rivosinc.com>
      Fixes: f4e11681 ("linux-user: Split out host_sig{segv,bus}_handler")
      Reviewed-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Message-Id: <33f27425878fb529b9e39ef22c303f6e0d90525f.camel@rivosinc.com>
      Signed-off-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      (cherry picked from commit 6d913158b5023ac948b8fd649d77fc86e28072f6)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      8bdd3abc
    • Fiona Ebner's avatar
      block/io: clear BDRV_BLOCK_RECURSE flag after recursing in bdrv_co_block_status · 99dd4a15
      Fiona Ebner authored
      
      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: default avatarFiona Ebner <f.ebner@proxmox.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
      Message-id: 20240116154839.401030-1-f.ebner@proxmox.com
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      (cherry picked from commit 8a9be7992426c8920d4178e7dca59306a18c7a3a)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      99dd4a15
    • Akihiko Odaki's avatar
      coroutine-ucontext: Save fake stack for pooled coroutine · f413f9fc
      Akihiko Odaki authored
      
      Coroutine may be pooled even after COROUTINE_TERMINATE if
      CONFIG_COROUTINE_POOL is enabled and fake stack should be saved in
      such a case to keep AddressSanitizerUseAfterReturn working. Even worse,
      I'm seeing stack corruption without fake stack being saved.
      
      Signed-off-by: default avatarAkihiko Odaki <akihiko.odaki@daynix.com>
      Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20240117-asan-v2-1-26f9e1ea6e72@daynix.com>
      (cherry picked from commit d9945ccda08ef83b09ac7725b6ee2d1959f2c0c0)
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      f413f9fc
Loading