qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] d8ad97: linux-user: xtensa: fix signal delive


From: Richard Henderson
Subject: [Qemu-commits] [qemu/qemu] d8ad97: linux-user: xtensa: fix signal delivery in FDPIC
Date: Thu, 14 Dec 2023 08:48:08 -0800

  Branch: refs/heads/staging-8.1
  Home:   https://github.com/qemu/qemu
  Commit: d8ad972b2d2361a369fc253505a0d2f7f2fec541
      
https://github.com/qemu/qemu/commit/d8ad972b2d2361a369fc253505a0d2f7f2fec541
  Author: Max Filippov <jcmvbkbc@gmail.com>
  Date:   2023-11-22 (Wed, 22 Nov 2023)

  Changed paths:
    M linux-user/xtensa/signal.c

  Log Message:
  -----------
  linux-user: xtensa: fix signal delivery in FDPIC

In FDPIC signal handlers are passed around as FD pointers. Actual code
address and GOT pointer must be fetched from memory by the QEMU code
that implements kernel signal delivery functionality. This change is
equivalent to the following kernel change:
9c2cc74fb31e ("xtensa: fix signal delivery to FDPIC process")

Cc: qemu-stable@nongnu.org
Fixes: d2796be69d7c ("linux-user: add support for xtensa FDPIC")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 1b173d06068c4a4e93fad88205399232925967a4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: db8e86cc40c22be3f3938d3e1f692511ec03b371
      
https://github.com/qemu/qemu/commit/db8e86cc40c22be3f3938d3e1f692511ec03b371
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-11-22 (Wed, 22 Nov 2023)

  Changed paths:
    M target/arm/tcg/sme_helper.c

  Log Message:
  -----------
  target/arm: Fix SME FMOPA (16-bit), BFMOPA

Perform the loop increment unconditionally, not nested
within the predication.

Cc: qemu-stable@nongnu.org
Fixes: 3916841ac75 ("target/arm: Implement FMOPA, FMOPS (widening)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1985
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20231117193135.1180657-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3efd8495735c69b863476e9003e624877382a72d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: c6c0a1888fc2339048157391eab2017cadbaf684
      
https://github.com/qemu/qemu/commit/c6c0a1888fc2339048157391eab2017cadbaf684
  Author: Niklas Cassel <niklas.cassel@wdc.com>
  Date:   2023-11-22 (Wed, 22 Nov 2023)

  Changed paths:
    M hw/ide/ahci.c

  Log Message:
  -----------
  hw/ide/ahci: fix legacy software reset

Legacy software contains a standard mechanism for generating a reset to a
Serial ATA device - setting the SRST (software reset) bit in the Device
Control register.

Serial ATA has a more robust mechanism called COMRESET, also referred to
as port reset. A port reset is the preferred mechanism for error
recovery and should be used in place of software reset.

Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
(mjt:  16cc9594d23d in stable-8.1 series, v8.1.1)
improved the handling of PxCI, such that PxCI gets cleared after handling
a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after
receiving anything - even a FIS that failed to parse, which should NOT
clear PxCI, so that you can see which command slot that caused an error).

However, simply clearing PxCI after a non-NCQ, or NCQ command, is not
enough, we also need to clear PxCI when receiving a SRST in the Device
Control register.

A legacy software reset is performed by the host sending two H2D FISes,
the first H2D FIS asserts SRST, and the second H2D FIS deasserts SRST.

The first H2D FIS will not get a D2H reply, and requires the FIS to have
the C bit set to one, such that the HBA itself will clear the bit in PxCI.

The second H2D FIS will get a D2H reply once the diagnostic is completed.
The clearing of the bit in PxCI for this command should ideally be done
in ahci_init_d2h() (if it was a legacy software reset that caused the
reset (a COMRESET does not use a command slot)). However, since the reset
value for PxCI is 0, modify ahci_reset_port() to actually clear PxCI to 0,
that way we can avoid complex logic in ahci_init_d2h().

This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.

Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-ID: <20231108222657.117984-1-nks@flawful.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit eabb921250666501ae78714b60090200b639fcfe)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(mjt: mention 16cc9594d23d for stable-8.1)


  Commit: cc5124d9797b0801525bc6658af9ed22426d1eff
      
https://github.com/qemu/qemu/commit/cc5124d9797b0801525bc6658af9ed22426d1eff
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M hw/net/allwinner-sun8i-emac.c
    M hw/net/allwinner_emac.c
    M hw/net/cadence_gem.c
    M hw/net/dp8393x.c
    M hw/net/e1000.c
    M hw/net/e1000e.c
    M hw/net/eepro100.c
    M hw/net/etraxfs_eth.c
    M hw/net/fsl_etsec/etsec.c
    M hw/net/ftgmac100.c
    M hw/net/i82596.c
    M hw/net/igb.c
    M hw/net/imx_fec.c
    M hw/net/lan9118.c
    M hw/net/mcf_fec.c
    M hw/net/mipsnet.c
    M hw/net/msf2-emac.c
    M hw/net/mv88w8618_eth.c
    M hw/net/ne2000-isa.c
    M hw/net/ne2000-pci.c
    M hw/net/npcm7xx_emc.c
    M hw/net/opencores_eth.c
    M hw/net/pcnet.c
    M hw/net/rocker/rocker_fp.c
    M hw/net/rtl8139.c
    M hw/net/smc91c111.c
    M hw/net/spapr_llan.c
    M hw/net/stellaris_enet.c
    M hw/net/sungem.c
    M hw/net/sunhme.c
    M hw/net/tulip.c
    M hw/net/virtio-net.c
    M hw/net/vmxnet3.c
    M hw/net/xen_nic.c
    M hw/net/xgmac.c
    M hw/net/xilinx_axienet.c
    M hw/net/xilinx_ethlite.c
    M hw/usb/dev-network.c
    M include/net/net.h
    M net/net.c

  Log Message:
  -----------
  net: Provide MemReentrancyGuard * to qemu_new_nic()

Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in I/O. The network device backend needs to update it
when delivering a packet to a device.

In preparation for such a change, add MemReentrancyGuard * as a
parameter of qemu_new_nic().

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 7d0fefdf81f5973334c344f6b8e1896c309dff66)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: fixup in hw/net/xen_nic.c due to lack of v8.1.0-2771-g25967ff69f
 "hw/xen: update Xen PV NIC to XenDevice model")


  Commit: 88e79a2dfda319f9ebec2cc8a5c3c9733716d13f
      
https://github.com/qemu/qemu/commit/88e79a2dfda319f9ebec2cc8a5c3c9733716d13f
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M include/net/net.h
    M net/net.c

  Log Message:
  -----------
  net: Update MemReentrancyGuard for NIC

Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in I/O. The network device backend needs to update it
when delivering a packet to a device.

This implementation follows what bottom half does, but it does not add
a tracepoint for the case that the network device backend started
delivering a packet to a device which is already engaging in I/O. This
is because such reentrancy frequently happens for
qemu_flush_queued_packets() and is insignificant.

Fixes: CVE-2023-3019
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 9050f976e447444ea6ee2ba12c9f77e4b0dc54bc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 983a4a828c64dba88386f3835d7e24528edbd29e
      
https://github.com/qemu/qemu/commit/983a4a828c64dba88386f3835d7e24528edbd29e
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M linux-user/elfload.c

  Log Message:
  -----------
  linux-user: Fix loaddr computation for some elf files

The file offset of the load segment is not relevant to the
low address, only the beginning of the virtual address page.

Cc: qemu-stable@nongnu.org
Fixes: a93934fecd4 ("elf: take phdr offset into account when calculating the 
program load address")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1952
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 82d70a84c8ee42ef969a9cfddc0f5b30b16165f5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5e7f6afe987ffd41204f46bd40d2cb2b4f987ecd
      
https://github.com/qemu/qemu/commit/5e7f6afe987ffd41204f46bd40d2cb2b4f987ecd
  Author: Thomas Huth <thuth@redhat.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M docs/devel/testing.rst
    M tests/avocado/cpu_queries.py
    M tests/avocado/empty_cpu_model.py
    M tests/avocado/pc_cpu_hotplug_props.py
    M tests/avocado/x86_cpu_model_versions.py

  Log Message:
  -----------
  tests/avocado: Replace assertEquals() for Python 3.12 compatibility

assertEquals() has been removed in Python 3.12 and should be replaced by
assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3

Message-ID: <20231114134326.287242-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 861f724d03e1748cda1c5b9ec8457a368590cbd5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: adjust context in pc_cpu_hotplug_props.py & cpu_queries.py for before
 v8.1.0-1582-g684750ab4f "python/qemu: rename command() to cmd()")


  Commit: 8328d7962106709fcb4f48e20a43291ffa872b55
      
https://github.com/qemu/qemu/commit/8328d7962106709fcb4f48e20a43291ffa872b55
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M docs/devel/testing.rst
    M tests/avocado/version.py

  Log Message:
  -----------
  tests/avocado: Replace assertRegexpMatches() for Python 3.12 compatibility

assertRegexpMatches() has been removed in Python 3.12 and should be replaced by
assertRegex(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3

Inspired-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20231114144832.71612-1-philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit f0a663b4ced2bf315936c774c2b6ff398fce8905)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: adjust context for before v8.1.0-1582-g684750ab4f
 "python/qemu: rename command() to cmd()")


  Commit: 8d0b8fead4c85addce1b0fa6132c9c8fc08fe06e
      
https://github.com/qemu/qemu/commit/8d0b8fead4c85addce1b0fa6132c9c8fc08fe06e
  Author: Palmer Dabbelt <palmer@rivosinc.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user/riscv: Add Zicboz block size to hwprobe

Support for probing the Zicboz block size landed in Linux 6.6, which was
released a few weeks ago.  This provides the user-configured block size
when Zicboz is enabled.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20231110173716.24423-1-palmer@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 301c65f49f9602f39b9f3ce0ad9ff70d4bda7226)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: fixup linux-user/syscall.c to before v8.1.0-2602-ge57039ddab
 "target/riscv: rename ext_icboz to ext_zicboz")


  Commit: 9ac76067abf74f8dc12f7c9ef2acb0df543ebcbb
      
https://github.com/qemu/qemu/commit/9ac76067abf74f8dc12f7c9ef2acb0df543ebcbb
  Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M hw/riscv/virt.c

  Log Message:
  -----------
  hw/riscv/virt.c: do create_fdt() earlier, add finalize_fdt()

Commit 49554856f0 fixed a problem, where TPM devices were not appearing
in the FDT, by delaying the FDT creation up until virt_machine_done().
This create a side effect (see gitlab #1925) - devices that need access
to the '/chosen' FDT node during realize() stopped working because, at
that point, we don't have a FDT.

This happens because our FDT creation is monolithic, but it doesn't need
to be. We can add the needed FDT components for realize() time and, at
the same time, do another FDT round where we account for dynamic sysbus
devices.  In other words, the problem fixed by 49554856f0 could also be
fixed by postponing only create_fdt_sockets() and its dependencies,
leaving everything else from create_fdt() to be done during init().

Split the FDT creation in two parts:

- create_fdt(), now moved back to virt_machine_init(), will create FDT
  nodes that doesn't depend on additional (dynamic) devices from the
  sysbus;

- a new finalize_fdt() step is added, where create_fdt_sockets() and
  friends is executed, accounting for the dynamic sysbus devices that
  were added during realize().

This will make both use cases happy: TPM devices are still working as
intended, and devices such as 'guest-loader' have a FDT to work on
during realize().

Fixes: 49554856f0 ("riscv: Generate devicetree only after machine 
initialization is complete")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1925
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20231110172559.73209-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 7a87ba8956e59bec8cc4677c6aa5141e4c023a7d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 837148a31ac68068cd8411118a96ada650bbbef9
      
https://github.com/qemu/qemu/commit/837148a31ac68068cd8411118a96ada650bbbef9
  Author: Román Cárdenas <rcardenas.rod@gmail.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M hw/riscv/sifive_e.c

  Log Message:
  -----------
  riscv: Fix SiFive E CLINT clock frequency

If you check the manual of SiFive E310 
(https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf),
you can see in Figure 1 that the CLINT is connected to the real time clock, 
which also feeds the AON peripheral (they share the same clock).
In page 43, the docs also say that the timer registers of the CLINT count ticks 
from the rtcclk.

I am currently playing with bare metal applications both in QEMU and a physical 
SiFive E310 board and
I confirm that the CLINT clock in the physical board runs at 32.768 kHz.
In QEMU, the same app produces a completely different outcome, as sometimes a 
new CLINT interrupt is triggered before finishing other tasks.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1978

Signed-off-by: Rom\ufffd\ufffdn C\ufffd\ufffdrdenas <rcardenas.rod@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20231117082840.55705-1-rcardenas.rod@gmail.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit a7472560ca5f7a61ef3a46b52118f680de81058c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 87ff608c6fd258c7f323e3a17f948e4e8d412d36
      
https://github.com/qemu/qemu/commit/87ff608c6fd258c7f323e3a17f948e4e8d412d36
  Author: Ivan Klokov <ivan.klokov@syntacore.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M target/riscv/cpu_helper.c

  Log Message:
  -----------
  target/riscv/cpu_helper.c: Invalid exception on MMU translation stage

According to RISCV privileged spec sect. 5.3.2 Virtual Address Translation 
Process
access-fault exceptions may raise only after PMA/PMP check. Current 
implementation
generates an access-fault for mbare mode even if there were no PMA/PMP errors.
This patch removes the erroneous MMU mode check and generates an access-fault
exception based on the pmp_violation flag only.

Fixes: 1448689c7b ("target/riscv: Allow specifying MMU stage")

Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20231121071757.7178-2-ivan.klokov@syntacore.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 82d53adfbb1aa0dbe7dac09b61ad86014efe81a7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6f51114b0ead04e51594d367328481ae21a55bcb
      
https://github.com/qemu/qemu/commit/6f51114b0ead04e51594d367328481ae21a55bcb
  Author: Ivan Klokov <ivan.klokov@syntacore.com>
  Date:   2023-11-29 (Wed, 29 Nov 2023)

  Changed paths:
    M target/riscv/cpu_helper.c

  Log Message:
  -----------
  target/riscv/cpu_helper.c: Fix mxr bit behavior

According to RISCV Specification sect 9.5 on two stage translation when
V=1 the vsstatus(mstatus in QEMU's terms) field MXR, which makes
execute-only pages readable, only overrides VS-stage page protection.
Setting MXR at HS-level(mstatus_hs), however, overrides both VS-stage
and G-stage execute-only permissions.

The hypervisor extension changes the behavior of MXR\MPV\MPRV bits.
Due to RISCV Specification sect. 9.4.1 when MPRV=1, explicit memory
accesses are translated and protected, and endianness is applied, as
though the current virtualization mode were set to MPV and the current
nominal privilege mode were set to MPP. vsstatus.MXR makes readable
those pages marked executable at the VS translation stage.

Fixes: 36a18664ba ("target/riscv: Implement second stage MMU")

Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20231121071757.7178-3-ivan.klokov@syntacore.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 6bca4d7d1ff2b8857486c3ff31f5c6fc3e3984b4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5cf2cf1f9f3f5b8e03ae6bad7604750eb8dd28d4
      
https://github.com/qemu/qemu/commit/5cf2cf1f9f3f5b8e03ae6bad7604750eb8dd28d4
  Author: Fam Zheng <fam@euphon.net>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M block/vmdk.c
    M tests/qemu-iotests/059
    M tests/qemu-iotests/059.out

  Log Message:
  -----------
  vmdk: Don't corrupt desc file in vmdk_write_cid

If the text description file is larger than DESC_SIZE, we force the last
byte in the buffer to be 0 and write it out.

This results in a corruption.

Try to allocate a big buffer in this case.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1923

Signed-off-by: Fam Zheng <fam@euphon.net>
Message-ID: <20231124115654.3239137-1-fam@euphon.net>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 9fb7b350ba9816ebca8a7614fec486fd4269ab2d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 169c593f78d936e85721acf54ff47dc436c4aefc
      
https://github.com/qemu/qemu/commit/169c593f78d936e85721acf54ff47dc436c4aefc
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M target/arm/syndrome.h

  Log Message:
  -----------
  target/arm: Set IL bit for pauth, SVE access, BTI trap syndromes

The syndrome register value always has an IL field at bit 25, which
is 0 for a trap on a 16 bit instruction, and 1 for a trap on a 32
bit instruction (or for exceptions which aren't traps on a known
instruction, like PC alignment faults). This means that our
syn_*() functions should always either take an is_16bit argument to
determine whether to set the IL bit, or else unconditionally set it.

We missed setting the IL bit for the syndrome for three kinds of trap:
 * an SVE access exception
 * a pointer authentication check failure
 * a BTI (branch target identification) check failure

All of these traps are AArch64 only, and so the instruction causing
the trap is always 64 bit. This means we can unconditionally set
the IL bit in the syn_*() function.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20231120150121.3458408-1-peter.maydell@linaro.org
Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 11a3c4a286d5dc603582ea0a1fca62c2ec0a1aee)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 49727560c7cfa4ddf71a14f0b259fb441a6a1792
      
https://github.com/qemu/qemu/commit/49727560c7cfa4ddf71a14f0b259fb441a6a1792
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M target/arm/helper.c
    M tests/tcg/aarch64/Makefile.softmmu-target
    A tests/tcg/aarch64/system/vtimer.c

  Log Message:
  -----------
  target/arm: Handle overflow in calculation of next timer tick

In commit edac4d8a168 back in 2015 when we added support for
the virtual timer offset CNTVOFF_EL2, we didn't correctly update
the timer-recalculation code that figures out when the timer
interrupt is next going to change state. We got it wrong in
two ways:
 * for the 0->1 transition, we didn't notice that gt->cval + offset
   can overflow a uint64_t
 * for the 1->0 transition, we didn't notice that the transition
   might now happen before the count rolls over, if offset > count

In the former case, we end up trying to set the next interrupt
for a time in the past, which results in QEMU hanging as the
timer fires continuously.

In the latter case, we would fail to update the interrupt
status when we are supposed to.

Fix the calculations in both cases.

The test case is Alex Bennée's from the bug report, and tests
the 0->1 transition overflow case.

Fixes: edac4d8a168 ("target-arm: Add CNTVOFF_EL2")
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/60
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20231120173506.3729884-1-peter.maydell@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 8d37a1425b9954d7e445615dcad23456515e24c0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 502f15db559c35ab38803c6071977e739a79c0b4
      
https://github.com/qemu/qemu/commit/502f15db559c35ab38803c6071977e739a79c0b4
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/virtio/virtio-iommu-pci.c

  Log Message:
  -----------
  hw/virtio: Free VirtIOIOMMUPCI::vdev.reserved_regions[] on finalize()

Commit 0be6bfac62 ("qdev: Implement variable length array properties")
added the DEFINE_PROP_ARRAY() macro with the following comment:

  * It is the responsibility of the device deinit code to free the
  * @_arrayfield memory.

Commit 8077b8e549 added:

  DEFINE_PROP_ARRAY("reserved-regions", VirtIOIOMMUPCI,
                    vdev.nb_reserved_regions, vdev.reserved_regions,
                    qdev_prop_reserved_region, ReservedRegion),

but forgot to free the 'vdev.reserved_regions' array. Do it in the
instance_finalize() handler.

Cc: qemu-stable@nongnu.org
Fixes: 8077b8e549 ("virtio-iommu-pci: Add array of Interval properties") # 
v5.1.0+
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Message-id: 20231121174051.63038-3-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit c9a4aa06dfce0fde1e279e1ea0c1945582ec0d16)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: fixup hw/virtio/virtio-iommu-pci.c for before v8.1.0-2552-g41cc70cdf5,
 "virtio-iommu: Rename reserved_regions into prop_resv_regions" -- so now
 patch subject matches actual change again)


  Commit: 48e0dfb837d8d4525a15d3faee6dd5b693efbaf0
      
https://github.com/qemu/qemu/commit/48e0dfb837d8d4525a15d3faee6dd5b693efbaf0
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/misc/mps2-scc.c

  Log Message:
  -----------
  hw/misc/mps2-scc: Free MPS2SCC::oscclk[] array on finalize()

Commit 0be6bfac62 ("qdev: Implement variable length array properties")
added the DEFINE_PROP_ARRAY() macro with the following comment:

  * It is the responsibility of the device deinit code to free the
  * @_arrayfield memory.

Commit 4fb013afcc added:

  DEFINE_PROP_ARRAY("oscclk", MPS2SCC, num_oscclk, oscclk_reset,
                    qdev_prop_uint32, uint32_t),

but forgot to free the 'oscclk_reset' array. Do it in the
instance_finalize() handler.

Cc: qemu-stable@nongnu.org
Fixes: 4fb013afcc ("hw/misc/mps2-scc: Support configurable number of OSCCLK 
values") # v6.0.0+
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20231121174051.63038-4-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 896dd6ff7b9f2575f1a908a07f26a70b58d8b675)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: a3e46300c59d423483a278772f41dc66dd3dc9f0
      
https://github.com/qemu/qemu/commit/a3e46300c59d423483a278772f41dc66dd3dc9f0
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/nvram/xlnx-efuse.c

  Log Message:
  -----------
  hw/nvram/xlnx-efuse: Free XlnxEFuse::ro_bits[] array on finalize()

Commit 0be6bfac62 ("qdev: Implement variable length array properties")
added the DEFINE_PROP_ARRAY() macro with the following comment:

  * It is the responsibility of the device deinit code to free the
  * @_arrayfield memory.

Commit 68fbcc344e added:

  DEFINE_PROP_ARRAY("read-only", XlnxEFuse, ro_bits_cnt, ro_bits,
                    qdev_prop_uint32, uint32_t),

but forgot to free the 'ro_bits' array. Do it in the instance_finalize
handler.

Cc: qemu-stable@nongnu.org
Fixes: 68fbcc344e ("hw/nvram: Introduce Xilinx eFuse QOM") # v6.2.0+
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20231121174051.63038-5-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 49b3e28b7bdfe771150d05c4b5860aa7854a4232)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f5584a7d8df9d27834342f94cca8ca2c7a86e206
      
https://github.com/qemu/qemu/commit/f5584a7d8df9d27834342f94cca8ca2c7a86e206
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/nvram/xlnx-versal-efuse-ctrl.c

  Log Message:
  -----------
  hw/nvram/xlnx-efuse-ctrl: Free XlnxVersalEFuseCtrl[] "pg0-lock" array

Commit 0be6bfac62 ("qdev: Implement variable length array properties")
added the DEFINE_PROP_ARRAY() macro with the following comment:

  * It is the responsibility of the device deinit code to free the
  * @_arrayfield memory.

Commit 9e4aa1fafe added:

  DEFINE_PROP_ARRAY("pg0-lock",
                    XlnxVersalEFuseCtrl, extra_pg0_lock_n16,
                    extra_pg0_lock_spec, qdev_prop_uint16, uint16_t),

but forgot to free the 'extra_pg0_lock_spec' array. Do it in the
instance_finalize() handler.

Cc: qemu-stable@nongnu.org
Fixes: 9e4aa1fafe ("hw/nvram: Xilinx Versal eFuse device") # v6.2.0+
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20231121174051.63038-6-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 4f10c66077e39969940d928077560665e155cac8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: fbca2cbbef1c9599290342bac0b93223d76b7d05
      
https://github.com/qemu/qemu/commit/fbca2cbbef1c9599290342bac0b93223d76b7d05
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/virtio/virtio-pci.c
    M include/hw/virtio/virtio-pci.h

  Log Message:
  -----------
  hw/virtio: Add VirtioPCIDeviceTypeInfo::instance_finalize field

The VirtioPCIDeviceTypeInfo structure, added in commit a4ee4c8baa
("virtio: Helper for registering virtio device types") got extended
in commit 8ea90ee690 ("virtio: add class_size") with the @class_size
field. Do similarly with the @instance_finalize field.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20231121174051.63038-2-philmd@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 837053a7f491b445088eac647abe7f462c50f59a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 66f14b70fe1b23ccf72a17c3324d95b38ee45a21
      
https://github.com/qemu/qemu/commit/66f14b70fe1b23ccf72a17c3324d95b38ee45a21
  Author: Gihun Nam <gihun.nam@outlook.com>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/avr/atmega.c
    M target/avr/cpu.c
    M target/avr/cpu.h

  Log Message:
  -----------
  hw/avr/atmega: Fix wrong initial value of stack pointer

The current implementation initializes the stack pointer of AVR devices
to 0. Although older AVR devices used to be like that, newer ones set
it to RAMEND.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1525
Signed-off-by: Gihun Nam <gihun.nam@outlook.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: 
<PH0P222MB0010877445B594724D40C924DEBDA@PH0P222MB0010.NAMP222.PROD.OUTLOOK.COM>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 235948bf53860a1e2df5134eae7b0a30a971a124)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 59de6e246fc7504ae78460df81e97d17f8fef2c6
      
https://github.com/qemu/qemu/commit/59de6e246fc7504ae78460df81e97d17f8fef2c6
  Author: Volker Rümelin <vr_qemu@t-online.de>
  Date:   2023-12-05 (Tue, 05 Dec 2023)

  Changed paths:
    M hw/audio/hda-codec.c

  Log Message:
  -----------
  hw/audio/hda-codec: fix multiplication overflow

After a relatively short time, there is an multiplication overflow
when multiplying (now - buft_start) with hda_bytes_per_second().
While the uptime now - buft_start only overflows after 2**63 ns
= 292.27 years, this happens hda_bytes_per_second() times faster
with the multiplication. At 44100 samples/s * 2 channels
* 2 bytes/channel = 176400 bytes/s that is 14.52 hours. After the
multiplication overflow the affected audio stream stalls.

Replace the multiplication and following division with muldiv64()
to prevent a multiplication overflow.

Fixes: 280c1e1cdb ("audio/hda: create millisecond timers that handle IO")
Reported-by: M_O_Bz <m_o_bz@163.com>
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20231105172552.8405-1-vr_qemu@t-online.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 74e8593e7e51d6b11ae9c56a3f4e7bb714bac4ec)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: ed7e167699912cb60c2127a2d4417f8cb2fa79ca
      
https://github.com/qemu/qemu/commit/ed7e167699912cb60c2127a2d4417f8cb2fa79ca
  Author: Akihiko Odaki <akihiko.odaki@daynix.com>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M hw/pci/pcie_sriov.c

  Log Message:
  -----------
  pcie_sriov: Remove g_new assertion

g_new() aborts if the allocation fails so it returns NULL only if the
requested allocation size is zero. register_vfs() makes such an
allocation if NumVFs is zero so it should not assert that g_new()
returns a non-NULL value.

Fixes: 7c0fa8dff8 ("pcie: Add support for Single Root I/O Virtualization 
(SR/IOV)")
Buglink: https://issues.redhat.com/browse/RHEL-17209
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20231123075630.12057-1-akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Yanghang Liu<yanghliu@redhat.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 714a1415d7a69174e1640fcdd6eaae180fe438aa)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5c9f4645313abf7d442cd038f9b9a5859612fb3e
      
https://github.com/qemu/qemu/commit/5c9f4645313abf7d442cd038f9b9a5859612fb3e
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M hw/acpi/erst.c

  Log Message:
  -----------
  hw/acpi/erst: Do not ignore Error* in realize handler

erst_realizefn() passes @errp to functions without checking for
failure.  If it runs into another failure, it trips error_setv()'s
assertion.

Use the ERRP_GUARD() macro and check *errp, as suggested in commit
ae7c80a7bd ("error: New macro ERRP_GUARD()").

Cc: qemu-stable@nongnu.org
Fixes: f7e26ffa59 ("ACPI ERST: support for ACPI ERST feature")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20231120130017.81286-1-philmd@linaro.org>
Reviewed-by: Ani Sinha <anisinha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 20bc50137f3add52eb4788b420d717de27fed14b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 701afca639c7c28ae13470b4ee124778dfd489cb
      
https://github.com/qemu/qemu/commit/701afca639c7c28ae13470b4ee124778dfd489cb
  Author: Robert Hoo <robert.hoo.linux@gmail.com>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M hw/pci/msix.c

  Log Message:
  -----------
  msix: unset PCIDevice::msix_vector_poll_notifier in rollback

In the rollback in msix_set_vector_notifiers(), original patch forgot to
undo msix_vector_poll_notifier pointer.

Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Robert Hoo <robert.hoo.linux@gmail.com>
Message-Id: <20231113081349.1307-1-robert.hoo.linux@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 2d37fe9e5e61b04bddbed00dbb7436e61a01c115)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5a92f023d970c902cdadbfc8c01edeea9b8258f5
      
https://github.com/qemu/qemu/commit/5a92f023d970c902cdadbfc8c01edeea9b8258f5
  Author: Antonio Caggiano <quic_acaggian@quicinc.com>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M ui/gtk-egl.c

  Log Message:
  -----------
  ui/gtk-egl: Check EGLSurface before doing scanout

The first time gd_egl_scanout_texture() is called, there's a possibility
that the GTK drawing area might not be realized yet, in which case its
associated GdkWindow is NULL. This means gd_egl_init() was also skipped
and the EGLContext and EGLSurface stored in the VirtualGfxConsole are
not valid yet.

Continuing with the scanout in this conditions would result in hitting
an assert in libepoxy: "Couldn't find current GLX or EGL context".

A possible workaround is to just ignore the scanout request, giving the
the GTK drawing area some time to finish its realization. At that point,
the gd_egl_init() will succeed and the EGLContext and EGLSurface stored
in the VirtualGfxConsole will be valid.

Signed-off-by: Antonio Caggiano <quic_acaggian@quicinc.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231016123215.2699269-1-quic_acaggian@quicinc.com>
(cherry picked from commit 6f189a08c1b0085808af1bfbf4567f0da193ecc1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5133410f8b0ccd873833bebcedf75f2cc60582ba
      
https://github.com/qemu/qemu/commit/5133410f8b0ccd873833bebcedf75f2cc60582ba
  Author: Volker Rümelin <vr_qemu@t-online.de>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M ui/gtk-egl.c

  Log Message:
  -----------
  ui/gtk-egl: move function calls back to regular code path

Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing
scanout") introduced a regression when QEMU is running with a
virtio-gpu-gl-device on a host under X11. After the guest has
initialized the virtio-gpu-gl-device, the guest screen only
shows "Display output is not active.".

Commit 6f189a08c1 moved all function calls in
gd_egl_scanout_texture() to a code path which is only called
once after gd_egl_init() succeeds in gd_egl_scanout_texture().
Move all function calls in gd_egl_scanout_texture() back to
the regular code path so they get always called if one of the
gd_egl_init() calls was successful.

Fixes: 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout")
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231111104020.26183-1-vr_qemu@t-online.de>
(cherry picked from commit 53a939f1bf8e4a3e38f9449fac44f572676966ad)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 4b2648356f337c1828d03898d38a68c8c3776c88
      
https://github.com/qemu/qemu/commit/4b2648356f337c1828d03898d38a68c8c3776c88
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M ui/vnc-clipboard.c

  Log Message:
  -----------
  ui/vnc-clipboard: fix inflate_buffer

Commit d921fea338 ("ui/vnc-clipboard: fix infinite loop in
inflate_buffer (CVE-2023-3255)") removed this hunk, but it is still
required, because it can happen that stream.avail_in becomes zero
before coming across a return value of Z_STREAM_END in the loop.

This fixes the host->guest direction of the clipboard with noVNC and
TigerVNC as clients.

Fixes: d921fea338 ("ui/vnc-clipboard: fix infinite loop in inflate_buffer 
(CVE-2023-3255)")
Reported-by: Friedrich Weber <f.weber@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20231122125826.228189-1-f.ebner@proxmox.com>
(cherry picked from commit ebfbf394671163c14e2b24d98f3927a3151d1aff)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 25d0ca4fb06a83bd32fb3e492fb77764b1a74c3a
      
https://github.com/qemu/qemu/commit/25d0ca4fb06a83bd32fb3e492fb77764b1a74c3a
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M target/arm/cpu.c

  Log Message:
  -----------
  target/arm: Disable SME if SVE is disabled

There is no architectural requirement that SME implies SVE, but
our implementation currently assumes it. (FEAT_SME_FA64 does
imply SVE.) So if you try to run a CPU with eg "-cpu max,sve=off"
you quickly run into an assert when the guest tries to write to
SMCR_EL1:

#6  0x00007ffff4b38e96 in __GI___assert_fail
    (assertion=0x5555566e69cb "sm", file=0x5555566e5b24 
"../../target/arm/helper.c", line=6865, function=0x5555566e82f0 
<__PRETTY_FUNCTION__.31> "sve_vqm1_for_el_sm") at ./assert/assert.c:101
#7  0x0000555555ee33aa in sve_vqm1_for_el_sm (env=0x555557d291f0, el=2, 
sm=false) at ../../target/arm/helper.c:6865
#8  0x0000555555ee3407 in sve_vqm1_for_el (env=0x555557d291f0, el=2) at 
../../target/arm/helper.c:6871
#9  0x0000555555ee3724 in smcr_write (env=0x555557d291f0, ri=0x555557da23b0, 
value=2147483663) at ../../target/arm/helper.c:6995
#10 0x0000555555fd1dba in helper_set_cp_reg64 (env=0x555557d291f0, 
rip=0x555557da23b0, value=2147483663) at ../../target/arm/tcg/op_helper.c:839
#11 0x00007fff60056781 in code_gen_buffer ()

Avoid this unsupported and slightly odd combination by
disabling SME when SVE is not present.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2005
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20231127173318.674758-1-peter.maydell@linaro.org
(cherry picked from commit f7767ca301796334f74b9b642b395a4bd3e3dbac)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: fab36df7bdc81656ff48f718a795e08257b49a9e
      
https://github.com/qemu/qemu/commit/fab36df7bdc81656ff48f718a795e08257b49a9e
  Author: Patrick Venture <venture@google.com>
  Date:   2023-12-13 (Wed, 13 Dec 2023)

  Changed paths:
    M softmmu/memory.c

  Log Message:
  -----------
  system/memory: use ldn_he_p/stn_he_p

Using direct pointer dereferencing can allow for unaligned accesses,
which was seen during execution with sanitizers enabled.

Cc: qemu-stable@nongnu.org
Reviewed-by: Chris Rauer <crauer@google.com>
Reviewed-by: Peter Foley <pefoley@google.com>
Signed-off-by: Patrick Venture <venture@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: David Hildenbrand <david@redhat.com>
Message-ID: <20231116163633.276671-1-venture@google.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 2b8fe81b3c2e76d241510a9a85496d544e42f5ec)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: b8311827286a08743a0257372b75fe98c0b8a67b
      
https://github.com/qemu/qemu/commit/b8311827286a08743a0257372b75fe98c0b8a67b
  Author: Kevin Wolf <kwolf@redhat.com>
  Date:   2023-12-14 (Thu, 14 Dec 2023)

  Changed paths:
    M blockdev.c

  Log Message:
  -----------
  block: Fix AioContext locking in qmp_block_resize()

The AioContext must be unlocked before calling blk_co_unref(), because
it takes the AioContext lock internally in blk_unref_bh(), which is
scheduled in the main thread. If we don't unlock, the AioContext is
locked twice and nested event loops such as in bdrv_graph_wrlock() will
deadlock.

Cc:  <qemu-stable@nongnu.org>
Fixes: https://issues.redhat.com/browse/RHEL-15965
Fixes: 0c7d204f50c382c6baac8c94bd57af4a022b3888
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20231208124352.30295-1-kwolf@redhat.com>
(cherry picked from commit 755ae3811fec77d94e92398632cbfe23c4ecffd5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 5b2fd6cf37352d671db09b54e4bc9d2ce707ca6d
      
https://github.com/qemu/qemu/commit/5b2fd6cf37352d671db09b54e4bc9d2ce707ca6d
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-12-14 (Thu, 14 Dec 2023)

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

  Log Message:
  -----------
  target/i386: Fix 32-bit wrapping of pc/eip computation

In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap.
Failure to do so results in incorrect memory exceptions to the guest.
Before 732d548732ed, this was implicitly done via truncation to
target_ulong but only in qemu-system-i386, not qemu-system-x86_64.

To fix this, we must add conditional zero-extensions.
Since we have to test for 32 vs 64-bit anyway, note that cs_base
is always zero in 64-bit mode.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
(cherry picked from commit b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in target/i386/tcg/tcg-cpu.c for v8.1.0-1190-gb77af26e97
 "accel/tcg: Replace CPUState.env_ptr with cpu_env()")


Compare: https://github.com/qemu/qemu/compare/179cc58e00ea...5b2fd6cf3735



reply via email to

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