qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] b769a8: block: Fix crash when loading snapsho


From: Alex Bennée
Subject: [Qemu-commits] [qemu/qemu] b769a8: block: Fix crash when loading snapshot on inactive...
Date: Mon, 29 Jan 2024 07:24:30 -0800

  Branch: refs/heads/stable-8.1
  Home:   https://github.com/qemu/qemu
  Commit: b769a8e472be68215ba6431f6e91d4bf8f537ff4
      
https://github.com/qemu/qemu/commit/b769a8e472be68215ba6431f6e91d4bf8f537ff4
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2023-12-22 (Fri, 22 Dec 2023)

  Changed paths:
    M block/snapshot.c

  Log Message:
  -----------
  block: Fix crash when loading snapshot on inactive node

bdrv_is_read_only() only checks if the node is configured to be
read-only eventually, but even if it returns false, writing to the node
may not be permitted at the moment (because it's inactive).

bdrv_is_writable() checks that the node can be written to right now, and
this is what the snapshot operations really need.

Change bdrv_can_snapshot() to use bdrv_is_writable() to fix crashes like
the following:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: ../block/io.c:1990: int bdrv_co_write_req_prepare(BdrvChild 
*, int64_t, int64_t, BdrvTrackedRequest *, int): Assertion `!(bs->open_flags & 
BDRV_O_INACTIVE)' failed.

The resulting error message after this patch isn't perfect yet, but at
least it doesn't crash any more:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-2-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d3007d348adaaf04ee8b099a475282034a662414)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 4c8315ad50e5a91a0666a8a14887deffb5d7d981
      
https://github.com/qemu/qemu/commit/4c8315ad50e5a91a0666a8a14887deffb5d7d981
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2023-12-22 (Fri, 22 Dec 2023)

  Changed paths:
    M softmmu/vl.c

  Log Message:
  -----------
  vl: Improve error message for conflicting -incoming and -loadvm

Currently, the conflict between -incoming and -loadvm is only detected
when loading the snapshot fails because the image is still inactive for
the incoming migration. This results in a suboptimal error message:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: Device 'ide0-hd0' is writable but does not support snapshots

Catch the situation already in qemu_validate_options() to improve the
message:

$ ./qemu-system-x86_64 -hda /tmp/test.qcow2 -loadvm foo -incoming defer
qemu-system-x86_64: 'incoming' and 'loadvm' options are mutually exclusive

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-3-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5a7f21efaf99c60614fe1967be1c0f9aa46c526e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 60472f719ca5a6cb7dc494f4daf6d3c712dffe62
      
https://github.com/qemu/qemu/commit/60472f719ca5a6cb7dc494f4daf6d3c712dffe62
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2023-12-22 (Fri, 22 Dec 2023)

  Changed paths:
    A tests/qemu-iotests/tests/qcow2-internal-snapshots
    A tests/qemu-iotests/tests/qcow2-internal-snapshots.out

  Log Message:
  -----------
  iotests: Basic tests for internal snapshots

We have a few test cases that include tests for corner case aspects of
internal snapshots, but nothing that tests that they actually function
as snapshots or that involves deleting a snapshot. Add a test for this
kind of basic internal snapshot functionality.

The error cases include a regression test for the crash we just fixed
with snapshot operations on inactive images.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20231201142520.32255-4-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit bb6e2511eb48539b7dcbcb5f47772e156b9c45d1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6c5dda7850082a78655ba4f11f6842d073423d07
      
https://github.com/qemu/qemu/commit/6c5dda7850082a78655ba4f11f6842d073423d07
  Author: Pavel Pisa <pisa@cmp.felk.cvut.cz>
  Date:   2024-01-05 (Fri, 05 Jan 2024)

  Changed paths:
    M hw/net/can/can_sja1000.c

  Log Message:
  -----------
  hw/net/can/sja1000: fix bug for single acceptance filter and standard frame

A CAN sja1000 standard frame filter mask has been computed and applied
incorrectly for standard frames when single Acceptance Filter Mode
(MOD_AFM = 1) has been selected. The problem has not been found
by Linux kernel testing because it uses dual filter mode (MOD_AFM = 0)
and leaves falters fully open.

The problem has been noticed by Grant Ramsay when testing with Zephyr
RTOS which uses single filter mode.

Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Reported-by: Grant Ramsay <gramsay@enphaseenergy.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2028
Fixes: 733210e754 ("hw/net/can: SJA1000 chip register level emulation")
Message-ID: <20240103231426.5685-1-pisa@fel.cvut.cz>
(cherry picked from commit 25145a7d7735344a469551946fc2a7f19eb4aa3d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 03382b91cb40ae02deeb711b6cd0f4c1a0830600
      
https://github.com/qemu/qemu/commit/03382b91cb40ae02deeb711b6cd0f4c1a0830600
  Author: Xu Lu <luxu.kernel@bytedance.com>
  Date:   2024-01-08 (Mon, 08 Jan 2024)

  Changed paths:
    M target/riscv/csr.c

  Log Message:
  -----------
  target/riscv: Fix mcycle/minstret increment behavior

The mcycle/minstret counter's stop flag is mistakenly updated on a copy
on stack. Thus the counter increments even when the CY/IR bit in the
mcountinhibit register is set. This commit corrects its behavior.

Fixes: 3780e33732f88 (target/riscv: Support mcycle/minstret write operation)
Signed-off-by: Xu Lu <luxu.kernel@bytedance.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 5cb0e7abe1635cb82e0033260dac2b910d142f8c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 97d3be7bca49708a797b0a961b2a4dd99030910f
      
https://github.com/qemu/qemu/commit/97d3be7bca49708a797b0a961b2a4dd99030910f
  Author: Michael Tokarev <mjt@tls.msk.ru>
  Date:   2024-01-08 (Mon, 08 Jan 2024)

  Changed paths:
    M chardev/char.c

  Log Message:
  -----------
  chardev/char.c: fix "abstract device type" error message

Current error message:

 qemu-system-x86_64: -chardev spice,id=foo: Parameter 'driver' expects an 
abstract device type

while in fact the meaning is in reverse, -chardev expects
a non-abstract device type.

Fixes: 777357d758d9 ("chardev: qom-ify" 2016-12-07)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit 4ad87cd4b2254197b7ac12e3da824854e6a90f8f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6eb6bca73f54e7d88f7a705abf727fdcc9e51c9a
      
https://github.com/qemu/qemu/commit/6eb6bca73f54e7d88f7a705abf727fdcc9e51c9a
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-01-11 (Thu, 11 Jan 2024)

  Changed paths:
    M hw/intc/arm_gicv3_cpuif.c

  Log Message:
  -----------
  hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registers

The hypervisor can deliver (virtual) LPIs to a guest by setting up a
list register to have an intid which is an LPI.  The GIC has to treat
these a little differently to standard interrupt IDs, because LPIs
have no Active state, and so the guest will only EOI them, it will
not also deactivate them.  So icv_eoir_write() must do two things:

 * if the LPI ID is not in any list register, we drop the
   priority but do not increment the EOI count
 * if the LPI ID is in a list register, we immediately deactivate
   it, regardless of the split-drop-and-deactivate control

This can be seen in the VirtualWriteEOIR0() and VirtualWriteEOIR1()
pseudocode in the GICv3 architecture specification.

Without this fix, potentially a hypervisor guest might stall because
LPIs get stuck in a bogus Active+Pending state.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
(cherry picked from commit 82a65e3188abebb509510b391726711606aca642)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 074b769c0bd48d19268ae3714202e320e9a31faa
      
https://github.com/qemu/qemu/commit/074b769c0bd48d19268ae3714202e320e9a31faa
  Author: Natanael Copa <ncopa@alpinelinux.org>
  Date:   2024-01-11 (Thu, 11 Jan 2024)

  Changed paths:
    M util/cpuinfo-ppc.c

  Log Message:
  -----------
  util: fix build with musl libc on ppc64le

Use PPC_FEATURE2_ISEL and PPC_FEATURE2_VEC_CRYPTO from linux headers
instead of the GNU specific PPC_FEATURE2_HAS_ISEL and
PPC_FEATURE2_HAS_VEC_CRYPTO. This fixes build with musl libc.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1861
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Fixes: 63922f467a ("tcg/ppc: Replace HAVE_ISEL macro with a variable")
Fixes: 68f340d4cd ("tcg/ppc: Enable Altivec detection")
Message-Id: <20231219105236.7059-1-ncopa@alpinelinux.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 1d513e06d96697f44de4a1b85c6ff627c443e306)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f62b55da87bf3278e4ef5c8c8696e2179498d37a
      
https://github.com/qemu/qemu/commit/f62b55da87bf3278e4ef5c8c8696e2179498d37a
  Author: Samuel Tardieu <sam@rfc1149.net>
  Date:   2024-01-13 (Sat, 13 Jan 2024)

  Changed paths:
    M tests/qtest/virtio-ccw-test.c

  Log Message:
  -----------
  tests/qtest/virtio-ccw: Fix device presence checking

An apparent copy-paste error tests for the presence of the
virtio-rng-ccw device in order to perform tests on the virtio-scsi-ccw
device.

Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Message-ID: <20240106130121.1244993-1-sam@rfc1149.net>
Fixes: 65331bf5d1 ("tests/qtest: Check for virtio-ccw devices before  using 
them")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit c98873ee4a0c2694aac976ab9affcf55da8b7e61)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5e190ed4152a1668f84cbf58b0daa65f3c5c2c0d
      
https://github.com/qemu/qemu/commit/5e190ed4152a1668f84cbf58b0daa65f3c5c2c0d
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2024-01-13 (Sat, 13 Jan 2024)

  Changed paths:
    M target/s390x/tcg/translate.c

  Log Message:
  -----------
  target/s390x: Fix LAE setting a wrong access register

LAE should set the access register corresponding to the first operand,
instead, it always modifies access register 1.

Co-developed-by: Ido Plat <Ido.Plat@ibm.com>
Cc: qemu-stable@nongnu.org
Fixes: a1c7610a6879 ("target-s390x: implement LAY and LAEY instructions")
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20240111092328.929421-2-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit e358a25a97c71c39e3513d9b869cdb82052e50b8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: target/s390x/tcg/translate.c: fixup for
 v8.1.0-1189-gad75a51e84 "tcg: Rename cpu_env to tcg_env")


  Commit: d6488e51867054f94e564fa6621933ab1437fe70
      
https://github.com/qemu/qemu/commit/d6488e51867054f94e564fa6621933ab1437fe70
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-01-13 (Sat, 13 Jan 2024)

  Changed paths:
    M .gitlab-ci.d/buildtest.yml

  Log Message:
  -----------
  .gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large

Sometimes the CI "pages" job fails with a message like this from
htags:

$ htags -anT --tree-view=filetree -m qemu_init -t "Welcome to the QEMU 
sourcecode"
htags: Negative exec line limit = -371

This is due to a bug in hflags where if the environment is too large it
falls over:
https://lists.gnu.org/archive/html/bug-global/2024-01/msg00000.html

This happens to us because GitLab CI puts the commit message of the
commit under test into the CI_COMMIT_MESSAGE and/or CI_COMMIT_TAG_MESSAGE
environment variables, so the job will fail if the commit happens to
have a verbose commit message.

Work around the htags bug by unsetting these variables while running
htags.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2080
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240111125543.1573473-1-peter.maydell@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 52a21689cd829c1cc931b59b5ee5bdb10dd578c1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 357b5990284107dfa36d234e3dcbf77e0e1367e0
      
https://github.com/qemu/qemu/commit/357b5990284107dfa36d234e3dcbf77e0e1367e0
  Author: Anastasia Belova <abelova@astralinux.ru>
  Date:   2024-01-19 (Fri, 19 Jan 2024)

  Changed paths:
    M include/hw/elf_ops.h

  Log Message:
  -----------
  load_elf: fix iterator's type for elf file processing

j is used while loading an ELF file to byteswap segments'
data. If data is larger than 2GB an overflow may happen.
So j should be elf_word.

This commit fixes a minor bug: it's unlikely anybody is trying to
load ELF files with 2GB+ segments for wrong-endianness targets,
but if they did, it wouldn't work correctly.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Cc: qemu-stable@nongnu.org
Fixes: 7ef295ea5b ("loader: Add data swap option to load-elf")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 410c2a4d75f52f6a2fe978eda5a9b6f854afe5ea)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 99e32260ac203040ea1f9c1c2930298ab1dee9cf
      
https://github.com/qemu/qemu/commit/99e32260ac203040ea1f9c1c2930298ab1dee9cf
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: Do not re-compute new pc with CF_PCREL

With PCREL, we have a page-relative view of EIP, and an
approximation of PC = EIP+CSBASE that is good enough to
detect page crossings.  If we try to recompute PC after
masking EIP, we will mess up that approximation and write
a corrupt value to EIP.

We already handled masking properly for PCREL, so the
fix in b5e0d5d2 was only needed for the !PCREL path.

Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4)
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 57078586026b2ff8c052f909a120118058a7fd57
      
https://github.com/qemu/qemu/commit/57078586026b2ff8c052f909a120118058a7fd57
  Author: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: fix incorrect EIP in PC-relative translation blocks

The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case.
Using s->pc in func gen_update_eip_next() solves the problem.

Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4)
Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 7b03b125ee36d0e98f12c80ca8a85d9597a7dc0e
      
https://github.com/qemu/qemu/commit/7b03b125ee36d0e98f12c80ca8a85d9597a7dc0e
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/tcg-cpu.c
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: pcrel: store low bits of physical address in data[0]

For PC-relative translation blocks, env->eip changes during the
execution of a translation block, Therefore, QEMU must be able to
recover an instruction's PC just from the TranslationBlock struct and
the instruction data with.  Because a TB will not span two pages, QEMU
stores all the low bits of EIP in the instruction data and replaces them
in x86_restore_state_to_opc.  Bits 12 and higher (which may vary between
executions of a PCREL TB, since these only use the physical address in
the hash key) are kept unmodified from env->eip.  The assumption is that
these bits of EIP, unlike bits 0-11, will not change as the translation
block executes.

Unfortunately, this is incorrect when the CS base is not aligned to a page.
Then the linear address of the instructions (i.e. the one with the
CS base addred) indeed will never span two pages, but bits 12+ of EIP
can actually change.  For example, if CS base is 0x80262200 and EIP =
0x6FF4, the first instruction in the translation block will be at linear
address 0x802691F4.  Even a very small TB will cross to EIP = 0x7xxx,
while the linear addresses will remain comfortably within a single page.

The fix is simply to use the low bits of the linear address for data[0],
since those don't change.  Then x86_restore_state_to_opc uses tb->cs_base
to compute a temporary linear address (referring to some unknown
instruction in the TB, but with the correct values of bits 12 and higher);
the low bits are replaced with data[0], and EIP is obtained by subtracting
again the CS base.

Huge thanks to Mark Cave-Ayland for the image and initial debugging,
and to Gitlab user @kjliew for help with bisecting another occurrence
of (hopefully!) the same bug.

It should be relatively easy to write a testcase that performs MMIO on
an EIP with different bits 12+ than the first instruction of the translation
block; any help is welcome.

Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11)
Cc: qemu-stable@nongnu.org
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Richard Henderson <richard.henderson@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: a8988972cd2c724019bbf409f3375eb0f958d020
      
https://github.com/qemu/qemu/commit/a8988972cd2c724019bbf409f3375eb0f958d020
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M backends/cryptodev.c

  Log Message:
  -----------
  backends/cryptodev: Do not ignore throttle/backends Errors

Both cryptodev_backend_set_throttle() and CryptoDevBackendClass::init()
can set their Error** argument. Do not ignore them, return early
on failure. Without that, running into another failure trips
error_setv()'s assertion. Use the ERRP_GUARD() macro as suggested
in commit ae7c80a7bd ("error: New macro ERRP_GUARD()").

Cc: qemu-stable@nongnu.org
Fixes: e7a775fd9f ("cryptodev: Account statistics")
Fixes: 2580b452ff ("cryptodev: support QoS")
Reviewed-by: zhenwei pi <pizhenwei@bytedance.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20231120150418.93443-1-philmd@linaro.org>
(cherry picked from commit 484aecf2d3a75251b63481be2a0c3aef635002af)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: d83b0f64aaa366744046db61c9caae9991f64940
      
https://github.com/qemu/qemu/commit/d83b0f64aaa366744046db61c9caae9991f64940
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c

  Log Message:
  -----------
  hw/pflash: refactor pflash_data_write()

Move the offset calculation, do it once at the start of the function and
let the 'p' variable point directly to the memory location which should
be updated.  This makes it simpler to update other buffers than
pfl->storage in an upcoming patch.  No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-2-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: dd25df302e8e3c6a095d70c9e23482683c56a14d
      
https://github.com/qemu/qemu/commit/dd25df302e8e3c6a095d70c9e23482683c56a14d
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c

  Log Message:
  -----------
  hw/pflash: use ldn_{be,le}_p and stn_{be,le}_p

Use the helper functions we have to read/write multi-byte values
in correct byte order.

Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-3-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: fcc79f2e09550b0461792491965fe202ed2219ae
      
https://github.com/qemu/qemu/commit/fcc79f2e09550b0461792491965fe202ed2219ae
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c
    M hw/block/pflash_cfi02.c
    M hw/block/trace-events

  Log Message:
  -----------
  hw/pflash: implement update buffer for block writes

Add an update buffer where all block updates are staged.
Flush or discard updates properly, so we should never see
half-completed block writes in pflash storage.

Drop a bunch of FIXME comments ;)

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-4-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: drop const in hw/block/pflash_cfi01.c for before
 v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState")


  Commit: 2472f8467d5ca0d7459a4c2ff3a0cbe2240c41ca
      
https://github.com/qemu/qemu/commit/2472f8467d5ca0d7459a4c2ff3a0cbe2240c41ca
  Author: Nick Briggs <nicholas.h.briggs@gmail.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M migration/rdma.c

  Log Message:
  -----------
  migration/rdma: define htonll/ntohll only if not predefined

Solaris has #defines for htonll and ntohll which cause syntax errors
when compiling code that attempts to (re)define these functions..

Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com>
Link: https://lore.kernel.org/r/65a04a7d.497ab3.3e7bef1f@gateway.sonic.net
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 44ce1b5d2fc77343f6a318cb3de613336a240048)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 2cd67d013dab3f7e0482a765acda70edffd8b786
      
https://github.com/qemu/qemu/commit/2cd67d013dab3f7e0482a765acda70edffd8b786
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: use correct address register for PCI DMA transfers

The current code in esp_pci_dma_memory_rw() sets the DMA address to the value
of the DMA_SPA (Starting Physical Address) register which is incorrect: this
means that for each callback from the SCSI layer the DMA address is set back
to the starting address.

In the case where only a single SCSI callback occurs (currently for transfer
lengths < 128kB) this works fine, however for larger transfers the DMA address
wraps back to the initial starting address, corrupting the buffer holding the
data transferred to the guest.

Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for
the DMA address which is correctly incremented across multiple SCSI layer
transfers.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: e8cb1260753863fe04c460b949a8d1aec304e3ee
      
https://github.com/qemu/qemu/commit/e8cb1260753863fe04c460b949a8d1aec304e3ee
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sources

The am53c974/dc390 PCI interrupt has two separate sources: the first is from the
internal ESP device, and the second is from the PCI DMA transfer logic.

Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than
driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function
to generate the correct PCI IRQ level. In particular this fixes spurious 
interrupts
being generated by setting DMA_STAT_DONE at the end of a transfer if 
DMA_CMD_INTE_D
isn't set in the DMA_CMD register.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 01db312e3bd4c2a834027dac83ad5a08f3573f6f
      
https://github.com/qemu/qemu/commit/01db312e3bd4c2a834027dac83ad5a08f3573f6f
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion 
interrupt

The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to
generate an interrupt, however the Linux driver manually checks for 
DMA_STAT_DONE
being set and if it is, considers that a DMA transfer has completed.

If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then
the Linux driver considers this to be a spurious interrupt. However this can
occur in QEMU as there is a delay between the end of DMA transfer where
DMA_STAT_DONE is set, and the ESP device raising its completion interrupt.

This appears to be an incorrect assumption in the Linux driver as the ESP and
PCI DMA interrupt sources are separate (and may not be raised exactly
together), however we can work around this by synchronising the setting of
DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt.

In conjunction with the previous commit Linux is now able to correctly boot
from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting
"iget: checksum invalid" and "Spurious irq, sreg=10" errors.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 72694a69c98723f51a0b4ab8113ab0362029c753
      
https://github.com/qemu/qemu/commit/72694a69c98723f51a0b4ab8113ab0362029c753
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issued

Even though the BLAST command isn't fully implemented in QEMU, the 
DMA_STAT_BCMBLT
bit should be set after the command has been issued to indicate that the command
has completed.

This fixes an issue with the DC390 DOS driver which issues the BLAST command as
part of its normal error recovery routine at startup, and otherwise sits in a
tight loop waiting for DMA_STAT_BCMBLT to be set before continuing.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 25ff741fe852123092fd9e80e887f0a20d843a10
      
https://github.com/qemu/qemu/commit/25ff741fe852123092fd9e80e887f0a20d843a10
  Author: Alex Bennée <alex.bennee@linaro.org>
  Date:   2024-01-23 (Tue, 23 Jan 2024)

  Changed paths:
    M .readthedocs.yml
    A docs/requirements.txt

  Log Message:
  -----------
  readthodocs: fully specify a build environment

This is now expected by rtd so I've expanded using their example as
22.04 is one of our supported platforms. I tried to work out if there
was an easy way to re-generate a requirements.txt from our
pythondeps.toml but in the end went for the easier solution.

Cc:  <qemu-stable@nongnu.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20231221174200.2693694-1-alex.bennee@linaro.org>
(cherry picked from commit b16a45bc5e0e329a16af8a2e020a6e7044f9afa2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 4b06bb5826bbfe735e2b75339c651884b5d77cbd
      
https://github.com/qemu/qemu/commit/4b06bb5826bbfe735e2b75339c651884b5d77cbd
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M accel/tcg/cpu-exec.c
    M accel/tcg/tb-maint.c
    M accel/tcg/translate-all.c

  Log Message:
  -----------
  accel/tcg: Revert mapping of PCREL translation block to multiple virtual 
addresses

This is causing regressions that have not been analyzed yet.  Revert the
change on stable branches.

Cc: qemu-stable@nongnu.org
Cc: Michael Tokarev <mjt@tls.msk.ru>
Related: https://gitlab.com/qemu-project/qemu/-/issues/2092
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 76a9da39d4ed0dde804cb67822dff72703ae6f74
      
https://github.com/qemu/qemu/commit/76a9da39d4ed0dde804cb67822dff72703ae6f74
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M block/io.c

  Log Message:
  -----------
  block/io: clear BDRV_BLOCK_RECURSE flag after recursing in 
bdrv_co_block_status

Using fleecing backup like in [0] on a qcow2 image (with metadata
preallocation) can lead to the following assertion failure:

> bdrv_co_do_block_status: Assertion `!(ret & BDRV_BLOCK_ZERO)' failed.

In the reproducer [0], it happens because the BDRV_BLOCK_RECURSE flag
will be set by the qcow2 driver, so the caller will recursively check
the file child. Then the BDRV_BLOCK_ZERO set too. Later up the call
chain, in bdrv_co_do_block_status() for the snapshot-access driver,
the assertion failure will happen, because both flags are set.

To fix it, clear the recurse flag after the recursive check was done.

In detail:

> #0  qcow2_co_block_status

Returns 0x45 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA |
BDRV_BLOCK_OFFSET_VALID.

> #1  bdrv_co_do_block_status

Because of the data flag, bdrv_co_do_block_status() will now also set
BDRV_BLOCK_ALLOCATED. Because of the recurse flag,
bdrv_co_do_block_status() for the bdrv_file child will be called,
which returns 0x16 = BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_OFFSET_VALID |
BDRV_BLOCK_ZERO. Now the return value inherits the zero flag.

Returns 0x57 = BDRV_BLOCK_RECURSE | BDRV_BLOCK_DATA |
BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_ALLOCATED | BDRV_BLOCK_ZERO.

> #2  bdrv_co_common_block_status_above
> #3  bdrv_co_block_status_above
> #4  bdrv_co_block_status
> #5  cbw_co_snapshot_block_status
> #6  bdrv_co_snapshot_block_status
> #7  snapshot_access_co_block_status
> #8  bdrv_co_do_block_status

Return value is propagated all the way up to here, where the assertion
failure happens, because BDRV_BLOCK_RECURSE and BDRV_BLOCK_ZERO are
both set.

> #9  bdrv_co_common_block_status_above
> #10 bdrv_co_block_status_above
> #11 block_copy_block_status
> #12 block_copy_dirty_clusters
> #13 block_copy_common
> #14 block_copy_async_co_entry
> #15 coroutine_trampoline

[0]:

> #!/bin/bash
> rm /tmp/disk.qcow2
> ./qemu-img create /tmp/disk.qcow2 -o preallocation=metadata -f qcow2 1G
> ./qemu-img create /tmp/fleecing.qcow2 -f qcow2 1G
> ./qemu-img create /tmp/backup.qcow2 -f qcow2 1G
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev 
> qcow2,node-name=node0,file.driver=file,file.filename=/tmp/disk.qcow2 \
> --blockdev 
> qcow2,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.qcow2 \
> --blockdev 
> qcow2,node-name=node2,file.driver=file,file.filename=/tmp/backup.qcow2 \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write", 
> "file": "node0", "target": "node1", "node-name": "node3" } }
> {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access", 
> "file": "node3", "node-name": "snap0" } }
> {"execute": "blockdev-backup", "arguments": { "device": "snap0", "target": 
> "node1", "sync": "full", "job-id": "backup0" } }
> EOF

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-id: 20240116154839.401030-1-f.ebner@proxmox.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 8a9be7992426c8920d4178e7dca59306a18c7a3a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: c173670033940211980fb78653f777fa1307d2a6
      
https://github.com/qemu/qemu/commit/c173670033940211980fb78653f777fa1307d2a6
  Author: Joseph Burt <caseorum@gmail.com>
  Date:   2024-01-25 (Thu, 25 Jan 2024)

  Changed paths:
    M tcg/arm/tcg-target.c.inc

  Log Message:
  -----------
  tcg/arm: Fix SIGILL in tcg_out_qemu_st_direct

When tcg_out_qemu_st_{index,direct} were merged, the direct case for
MO_64 was omitted, causing qemu_st_i64 to be encoded as 0xffffffff due
to underflow when adding h.base and h.index.

Fixes: 1df6d611bdc2 ("tcg/arm: Introduce HostAddress")
Signed-off-by: Joseph Burt <caseorum@gmail.com>
Message-Id: <20240121211439.100829-1-caseorum@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 9f6523e8e4689cafdbed7c10b7cf7c775b5a607b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: dd1d3c8c29144e8e3bb89d18fd7feed4b65d328d
      
https://github.com/qemu/qemu/commit/dd1d3c8c29144e8e3bb89d18fd7feed4b65d328d
  Author: Jason Wang <jasowang@redhat.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M hw/net/virtio-net.c

  Log Message:
  -----------
  virtio-net: correctly copy vnet header when flushing TX

When HASH_REPORT is negotiated, the guest_hdr_len might be larger than
the size of the mergeable rx buffer header. Using
virtio_net_hdr_mrg_rxbuf during the header swap might lead a stack
overflow in this case. Fixing this by using virtio_net_hdr_v1_hash
instead.

Reported-by: Xiao Lei <leixiao.nop@zju.edu.cn>
Cc: Yuri Benditovich <yuri.benditovich@daynix.com>
Cc: qemu-stable@nongnu.org
Cc: Mauro Matteo Cascella <mcascell@redhat.com>
Fixes: CVE-2023-6693
Fixes: e22f0603fb2f ("virtio-net: reference implementation of hash report")
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 2220e8189fb94068dbad333228659fbac819abb0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 23a512f418daa8daca774535eb5af33c4bc04640
      
https://github.com/qemu/qemu/commit/23a512f418daa8daca774535eb5af33c4bc04640
  Author: Ari Sundholm <ari@tuxera.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M block/blklogwrites.c

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

There is a bug in the blklogwrites driver pertaining to logging "write
zeroes" operations, causing log corruption. This can be easily observed
by setting detect-zeroes to something other than "off" for the driver.

The issue is caused by a concurrency bug pertaining to the fact that
"write zeroes" operations have to be logged in two parts: first the log
entry metadata, then the zeroed-out region. While the log entry
metadata is being written by bdrv_co_pwritev(), another operation may
begin in the meanwhile and modify the state of the blklogwrites driver.
This is as intended by the coroutine-driven I/O model in QEMU, of
course.

Unfortunately, this specific scenario is mishandled. A short example:
    1. Initially, in the current operation (#1), the current log sector
number in the driver state is only incremented by the number of sectors
taken by the log entry metadata, after which the log entry metadata is
written. The current operation yields.
    2. Another operation (#2) may start while the log entry metadata is
being written. It uses the current log position as the start offset for
its log entry. This is in the sector right after the operation #1 log
entry metadata, which is bad!
    3. After bdrv_co_pwritev() returns (#1), the current log sector
number is reread from the driver state in order to find out the start
offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the
offset will be the sector right after the (misplaced) operation #2 log
entry, which means that the zeroed-out region begins at the wrong
offset.
    4. As a result of the above, the log is corrupt.

Fix this by only reading the driver metadata once, computing the
offsets and sizes in one go (including the optional zeroed-out region)
and setting the log sector number to the appropriate value for the next
operation in line.

Signed-off-by: Ari Sundholm <ari@tuxera.com>
Cc: qemu-stable@nongnu.org
Message-ID: <20240109184646.1128475-1-megari@gmx.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a9c8ea95470c27a8a02062b67f9fa6940e828ab6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 03bc938fbfcde3cdc11eb00d30b407d2dd80448d
      
https://github.com/qemu/qemu/commit/03bc938fbfcde3cdc11eb00d30b407d2dd80448d
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M tests/qemu-iotests/iotests.py

  Log Message:
  -----------
  iotests: add filter_qmp_generated_node_ids()

Add a filter function for QMP responses that contain QEMU's
automatically generated node ids. The ids change between runs and must
be masked in the reference output.

The next commit will use this new function.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit da62b507a20510d819bcfbe8f5e573409b954006)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 2f5e27eefa0d99ed9d0b8c9621e8c9f877b1d3cd
      
https://github.com/qemu/qemu/commit/2f5e27eefa0d99ed9d0b8c9621e8c9f877b1d3cd
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M tests/qemu-iotests/141
    M tests/qemu-iotests/141.out

  Log Message:
  -----------
  iotests: port 141 to Python for reliable QMP testing

The common.qemu bash functions allow tests to interact with the QMP
monitor of a QEMU process. I spent two days trying to update 141 when
the order of the test output changed, but found it would still fail
occassionally because printf() and QMP events race with synchronous QMP
communication.

I gave up and ported 141 to the existing Python API for QMP tests. The
Python API is less affected by the order in which QEMU prints output
because it does not print all QMP traffic by default.

The next commit changes the order in which QMP messages are received.
Make 141 reliable first.

Cc: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 9ee2dd4c22a3639c5462b3fc20df60c005c3de64)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 4b02c718b59104a3c69f1e5f5d6932961474442d
      
https://github.com/qemu/qemu/commit/4b02c718b59104a3c69f1e5f5d6932961474442d
  Author: Stefan Hajnoczi <stefanha@redhat.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M monitor/qmp.c
    M qapi/qmp-dispatch.c
    M tests/qemu-iotests/060.out
    M tests/qemu-iotests/071.out
    M tests/qemu-iotests/081.out
    M tests/qemu-iotests/087.out
    M tests/qemu-iotests/108.out
    M tests/qemu-iotests/109
    M tests/qemu-iotests/109.out
    M tests/qemu-iotests/117.out
    M tests/qemu-iotests/120.out
    M tests/qemu-iotests/127.out
    M tests/qemu-iotests/140.out
    M tests/qemu-iotests/143.out
    M tests/qemu-iotests/156.out
    M tests/qemu-iotests/176.out
    M tests/qemu-iotests/182.out
    M tests/qemu-iotests/183.out
    M tests/qemu-iotests/184.out
    M tests/qemu-iotests/185
    M tests/qemu-iotests/185.out
    M tests/qemu-iotests/191.out
    M tests/qemu-iotests/195.out
    M tests/qemu-iotests/223.out
    M tests/qemu-iotests/227.out
    M tests/qemu-iotests/247.out
    M tests/qemu-iotests/273.out
    M tests/qemu-iotests/308
    M tests/qemu-iotests/308.out
    M tests/qemu-iotests/tests/file-io-error
    M tests/qemu-iotests/tests/iothreads-resize.out
    M tests/qemu-iotests/tests/qsd-jobs.out

  Log Message:
  -----------
  monitor: only run coroutine commands in qemu_aio_context

monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not
polled during nested event loops. The coroutine currently reschedules
itself in the main loop's qemu_aio_context AioContext, which is polled
during nested event loops. One known problem is that QMP device-add
calls drain_call_rcu(), which temporarily drops the BQL, leading to all
sorts of havoc like other vCPU threads re-entering device emulation code
while another vCPU thread is waiting in device emulation code with
aio_poll().

Paolo Bonzini suggested running non-coroutine QMP handlers in the
iohandler AioContext. This avoids trouble with nested event loops. His
original idea was to move coroutine rescheduling to
monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch()
because we don't know if the QMP handler needs to run in coroutine
context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have
been nicer since it's associated with the monitor implementation and not
as general as qmp_dispatch(), which is also used by qemu-ga.

A number of qemu-iotests need updated .out files because the order of
QMP events vs QMP responses has changed.

Solves Issue #1933.

Cc: qemu-stable@nongnu.org
Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use 
drain_call_rcu in in qmp_device_add")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985
Buglink: https://issues.redhat.com/browse/RHEL-17369
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit effd60c878176bcaf97fa7ce2b12d04bb8ead6f7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: d24dd1014336d2aefd1e3a431c15b38279a46d40
      
https://github.com/qemu/qemu/commit/d24dd1014336d2aefd1e3a431c15b38279a46d40
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   2024-01-26 (Fri, 26 Jan 2024)

  Changed paths:
    M tests/qtest/meson.build

  Log Message:
  -----------
  qtest: bump aspeed_smc-test timeout to 6 minutes

On a loaded system with --enable-debug, this test can take longer than
5 minutes. Raising the timeout to 6 minutes gives greater headroom for
such situations.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
[thuth: Increase the timeout to 6 minutes for very loaded systems]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20231215070357.10888-11-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit e8a12fe31f776c60fec993513cd1b1e66c2b8e29)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fixup in tests/qtest/meson.build)


  Commit: b86fa3a4f2daa78ae99240d1f49bfe362d65b687
      
https://github.com/qemu/qemu/commit/b86fa3a4f2daa78ae99240d1f49bfe362d65b687
  Author: Max Filippov <jcmvbkbc@gmail.com>
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
    M target/xtensa/mmu_helper.c

  Log Message:
  -----------
  target/xtensa: fix OOB TLB entry access

r[id]tlb[01], [iw][id]tlb opcodes use TLB way index passed in a register
by the guest. The host uses 3 bits of the index for ITLB indexing and 4
bits for DTLB, but there's only 7 entries in the ITLB array and 10 in
the DTLB array, so a malicious guest may trigger out-of-bound access to
these arrays.

Change split_tlb_entry_spec return type to bool to indicate whether TLB
way passed to it is valid. Change get_tlb_entry to return NULL in case
invalid TLB way is requested. Add assertion to xtensa_tlb_get_entry that
requested TLB way and entry indices are valid. Add checks to the
[rwi]tlb helpers that requested TLB way is valid and return 0 or do
nothing when it's not.

Cc: qemu-stable@nongnu.org
Fixes: b67ea0cd7441 ("target-xtensa: implement memory protection options")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20231215120307.545381-1-jcmvbkbc@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 604927e357c2b292c70826e4ce42574ad126ef32)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: ccdb4cc2094a27ca77425b056f4c30b5a57f32d4
      
https://github.com/qemu/qemu/commit/ccdb4cc2094a27ca77425b056f4c30b5a57f32d4
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
    M target/arm/tcg/translate-a64.c

  Log Message:
  -----------
  target/arm: Fix A64 scalar SQSHRN and SQRSHRN

In commit 1b7bc9b5c8bf374dd we changed handle_vec_simd_sqshrn() so
that instead of starting with a 0 value and depositing in each new
element from the narrowing operation, it instead started with the raw
result of the narrowing operation of the first element.

This is fine in the vector case, because the deposit operations for
the second and subsequent elements will always overwrite any higher
bits that might have been in the first element's result value in
tcg_rd.  However in the scalar case we only go through this loop
once.  The effect is that for a signed narrowing operation, if the
result is negative then we will now return a value where the bits
above the first element are incorrectly 1 (because the narrowfn
returns a sign-extended result, not one that is truncated to the
element size).

Fix this by using an extract operation to get exactly the correct
bits of the output of the narrowfn for element 1, instead of a
plain move.

Cc: qemu-stable@nongnu.org
Fixes: 1b7bc9b5c8bf374dd3 ("target/arm: Avoid tcg_const_ptr in 
handle_vec_simd_sqshrn")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2089
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20240123153416.877308-1-peter.maydell@linaro.org
(cherry picked from commit 6fffc8378562c7fea6290c430b4f653f830a4c1a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 20a1b341a0af1fef84cec9e521d33da0e8d9ecf3
      
https://github.com/qemu/qemu/commit/20a1b341a0af1fef84cec9e521d33da0e8d9ecf3
  Author: Michael Tokarev <mjt@tls.msk.ru>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M VERSION

  Log Message:
  -----------
  Update version for 8.1.5 release

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/c95e38d33beb...20a1b341a0af



reply via email to

[Prev in Thread] Current Thread [Next in Thread]