qemu-commits
[Top][All Lists]
Advanced

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

[Qemu-commits] [qemu/qemu] 8eb73a: hw/remote: Fix vfu_cfg trace offset f


From: npiggin
Subject: [Qemu-commits] [qemu/qemu] 8eb73a: hw/remote: Fix vfu_cfg trace offset format
Date: Thu, 29 Jun 2023 23:03:17 -0700

  Branch: refs/heads/staging-7.2
  Home:   https://github.com/qemu/qemu
  Commit: 8eb73afedc143f5ca4798d055a4cc7de39194c6c
      
https://github.com/qemu/qemu/commit/8eb73afedc143f5ca4798d055a4cc7de39194c6c
  Author: Mattias Nissler <mnissler@rivosinc.com>
  Date:   2023-06-11 (Sun, 11 Jun 2023)

  Changed paths:
    M hw/remote/trace-events

  Log Message:
  -----------
  hw/remote: Fix vfu_cfg trace offset format

The printed offset value is prefixed with 0x, but was actually printed
in decimal. To spare others the confusion, adjust the format specifier
to hexadecimal.

Signed-off-by: Mattias Nissler <mnissler@rivosinc.com>
Reviewed-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 5fb9e8295531f957cf7ac20e89736c8963a25e04)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 9b55660e4a4f6bfea0965b2567641492a1feac57
      
https://github.com/qemu/qemu/commit/9b55660e4a4f6bfea0965b2567641492a1feac57
  Author: Anastasia Belova <abelova@astralinux.ru>
  Date:   2023-06-11 (Sun, 11 Jun 2023)

  Changed paths:
    M ui/vnc-jobs.c

  Log Message:
  -----------
  vnc: move assert in vnc_worker_thread_loop

job may be NULL if queue->exit is true. Check
it before dereference job.

Fixes: f31f9c1080 ("vnc: add magic cookie to VncState")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit bdfca8a22f41e7ad47fd2dac71e4d1387e2c0d4e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: d31e0a384391c072bb121816ce9b7582a65cad9d
      
https://github.com/qemu/qemu/commit/d31e0a384391c072bb121816ce9b7582a65cad9d
  Author: Nicholas Piggin <npiggin@gmail.com>
  Date:   2023-06-11 (Sun, 11 Jun 2023)

  Changed paths:
    M target/ppc/translate.c

  Log Message:
  -----------
  target/ppc: Fix lqarx to set cpu_reserve

lqarx does not set cpu_reserve, which causes stqcx. to never succeed.

Cc: qemu-stable@nongnu.org
Fixes: 94bf2658676 ("target/ppc: Use atomic load for LQ and LQARX")
Fixes: 57b38ffd0c6 ("target/ppc: Use tcg_gen_qemu_{ld,st}_i128 for LQARX, LQ, 
STQ")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230605025445.161932-1-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
(cherry picked from commit e025e8f5a8a7e32409bb4c7c509d752486113188)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 8e57e02ff8f655a0fca6877299e26454cc2d1165
      
https://github.com/qemu/qemu/commit/8e57e02ff8f655a0fca6877299e26454cc2d1165
  Author: Nicholas Piggin <npiggin@gmail.com>
  Date:   2023-06-11 (Sun, 11 Jun 2023)

  Changed paths:
    M target/ppc/excp_helper.c

  Log Message:
  -----------
  target/ppc: Fix nested-hv HEAI delivery

ppc hypervisors turn HEAI interrupts into program interrupts injected
into the guest that executed the illegal instruction, if the hypervisor
doesn't handle it some other way.

The nested-hv implementation failed to account for this HEAI->program
conversion. The virtual hypervisor wants to see the HEAI when running
a nested guest, so that interrupt type can be returned to its KVM
caller.

Fixes: 7cebc5db2eba6 ("target/ppc: Introduce a vhyp framework for nested HV 
support")
Cc: balaton@eik.bme.hu
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-Id: <20230530132127.385001-1-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
(cherry picked from commit 6c242e79b876b3570b8fd2f10f2a502467758e56)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6e979dba56845f472496a86e290dd56ba7431ccd
      
https://github.com/qemu/qemu/commit/6e979dba56845f472496a86e290dd56ba7431ccd
  Author: Nicholas Piggin <npiggin@gmail.com>
  Date:   2023-06-11 (Sun, 11 Jun 2023)

  Changed paths:
    M target/ppc/cpu_init.c
    M target/ppc/helper_regs.c
    M target/ppc/helper_regs.h
    M target/ppc/machine.c
    M target/ppc/power8-pmu.c
    M target/ppc/power8-pmu.h

  Log Message:
  -----------
  target/ppc: Fix PMU hflags calculation

Some of the PMU hflags bits can go out of synch, for example a store to
MMCR0 with PMCjCE=1 fails to update hflags correctly and results in
hflags mismatch:

  qemu: fatal: TCG hflags mismatch (current:0x2408003d rebuilt:0x240a003d)

This can be reproduced by running perf on a recent machine.

Some of the fragility here is the duplication of PMU hflags calculations.
This change consolidates that in a single place to update pmu-related
hflags, to be called after a well defined state changes.

The post-load PMU update is pulled out of the MSR update because it does
not depend on the MSR value.

Fixes: 8b3d1c49a9f0 ("target/ppc: Add new PMC HFLAGS")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20230530130447.372617-1-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
(cherry picked from commit 6494d2c1fd4ebc37b575130399a97a1fcfff1afc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 4fc28bf08a147f24c4817fa740e24d458ed29ec2
      
https://github.com/qemu/qemu/commit/4fc28bf08a147f24c4817fa740e24d458ed29ec2
  Author: Yin Wang <yin.wang@intel.com>
  Date:   2023-06-14 (Wed, 14 Jun 2023)

  Changed paths:
    M hw/riscv/numa.c

  Log Message:
  -----------
  hw/riscv: qemu crash when NUMA nodes exceed available CPUs

Command "qemu-system-riscv64 -machine virt
-m 2G -smp 1 -numa node,mem=1G -numa node,mem=1G"
would trigger this problem.Backtrace with:
 #0  0x0000555555b5b1a4 in riscv_numa_get_default_cpu_node_id  at 
../hw/riscv/numa.c:211
 #1  0x00005555558ce510 in machine_numa_finish_cpu_init  at 
../hw/core/machine.c:1230
 #2  0x00005555558ce9d3 in machine_run_board_init  at ../hw/core/machine.c:1346
 #3  0x0000555555aaedc3 in qemu_init_board  at ../softmmu/vl.c:2513
 #4  0x0000555555aaf064 in qmp_x_exit_preconfig  at ../softmmu/vl.c:2609
 #5  0x0000555555ab1916 in qemu_init  at ../softmmu/vl.c:3617
 #6  0x000055555585463b in main  at ../softmmu/main.c:47
This commit fixes the issue by adding parameter checks.

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn>
Signed-off-by: Yin Wang <yin.wang@intel.com>
Message-Id: <20230519023758.1759434-1-yin.wang@intel.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit b9cedbf19cb4be04908a3a623f0f237875483499)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 23315ad0b8c04423fd274e9c571ae2cee9bd50c2
      
https://github.com/qemu/qemu/commit/23315ad0b8c04423fd274e9c571ae2cee9bd50c2
  Author: Cédric Le Goater <clg@kaod.org>
  Date:   2023-06-16 (Fri, 16 Jun 2023)

  Changed paths:
    M hw/misc/aspeed_hace.c

  Log Message:
  -----------
  aspeed/hace: Initialize g_autofree pointer

As mentioned in docs/devel/style.rst "Automatic memory deallocation":

* Variables declared with g_auto* MUST always be initialized,
  otherwise the cleanup function will use uninitialized stack memory

This avoids QEMU to coredump when running the "hash test" command
under Zephyr.

Cc: Steven Lee <steven_lee@aspeedtech.com>
Cc: Joel Stanley <joel@jms.id.au>
Cc: qemu-stable@nongnu.org
Fixes: c5475b3f9a ("hw: Model ASPEED's Hash and Crypto Engine")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com>
Message-Id: <20230421131547.2177449-1-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit c8f48b120b31f6bbe33135ef5d478e485c37e3c2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 1bc596d079dba75794560e0b52f1b0cb7d5dd3a4
      
https://github.com/qemu/qemu/commit/1bc596d079dba75794560e0b52f1b0cb7d5dd3a4
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-22 (Thu, 22 Jun 2023)

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

  Log Message:
  -----------
  target/arm: Fix return value from LDSMIN/LDSMAX 8/16 bit atomics

The atomic memory operations are supposed to return the old memory
data value in the destination register.  This value is not
sign-extended, even if the operation is the signed minimum or
maximum.  (In the pseudocode for the instructions the returned data
value is passed to ZeroExtend() to create the value in the register.)

We got this wrong because we were doing a 32-to-64 zero extend on the
result for 8 and 16 bit data values, rather than the correct amount
of zero extension.

Fix the bug by using ext8u and ext16u for the MO_8 and MO_16 data
sizes rather than ext32u.

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


  Commit: d0040c60f7185477fe0080e6d09f052adf86c572
      
https://github.com/qemu/qemu/commit/d0040c60f7185477fe0080e6d09f052adf86c572
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-22 (Thu, 22 Jun 2023)

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

  Log Message:
  -----------
  target/arm: Return correct result for LDG when ATA=0

The LDG instruction loads the tag from a memory address (identified
by [Xn + offset]), and then merges that tag into the destination
register Xt. We implemented this correctly for the case when
allocation tags are enabled, but didn't get it right when ATA=0:
instead of merging the tag bits into Xt, we merged them into the
memory address [Xn + offset] and then set Xt to that.

Merge the tag bits into the old Xt value, as they should be.

Cc: qemu-stable@nongnu.org
Fixes: c15294c1e36a7dd9b25 ("target/arm: Implement LDG, STG, ST2G instructions")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 7e2788471f9e079fff696a694721a7d41a451839)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 09dd3f2cae7606fb9282eda820ef9324f6d4383f
      
https://github.com/qemu/qemu/commit/09dd3f2cae7606fb9282eda820ef9324f6d4383f
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-22 (Thu, 22 Jun 2023)

  Changed paths:
    M hw/intc/allwinner-a10-pic.c

  Log Message:
  -----------
  hw/intc/allwinner-a10-pic: Handle IRQ levels other than 0 or 1

In commit 2c5fa0778c3b430 we fixed an endianness bug in the Allwinner
A10 PIC model; however in the process we introduced a regression.
This is because the old code was robust against the incoming 'level'
argument being something other than 0 or 1, whereas the new code was
not.

In particular, the allwinner-sdhost code treats its IRQ line
as 0-vs-non-0 rather than 0-vs-1, so when the SD controller
set its IRQ line for any reason other than transmit the
interrupt controller would ignore it. The observed effect
was a guest timeout when rebooting the guest kernel.

Handle level values other than 0 or 1, to restore the old
behaviour.

Fixes: 2c5fa0778c3b430 ("hw/intc/allwinner-a10-pic: Don't use 
set_bit()/clear_bit()")
(Mjt:  5eb742fce562dc7 in stable-7.2)
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-id: 20230606104609.3692557-2-peter.maydell@linaro.org
(cherry picked from commit f837b468cdaa7e736b5385c7dc4f8c5adcad3bf1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 04de6cb0027c86e628ae0c64ca06b6f05b475c53
      
https://github.com/qemu/qemu/commit/04de6cb0027c86e628ae0c64ca06b6f05b475c53
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-22 (Thu, 22 Jun 2023)

  Changed paths:
    M hw/timer/nrf51_timer.c

  Log Message:
  -----------
  hw/timer/nrf51_timer: Don't lose time when timer is queried in tight loop

The nrf51_timer has a free-running counter which we implement using
the pattern of using two fields (update_counter_ns, counter) to track
the last point at which we calculated the counter value, and the
counter value at that time.  Then we can find the current counter
value by converting the difference in wall-clock time between then
and now to a tick count that we need to add to the counter value.

Unfortunately the nrf51_timer's implementation of this has a bug
which means it loses time every time update_counter() is called.
After updating s->counter it always sets s->update_counter_ns to
'now', even though the actual point when s->counter hit the new value
will be some point in the past (half a tick, say).  In the worst case
(guest code in a tight loop reading the counter, icount mode) the
counter is continually queried less than a tick after it was last
read, so s->counter never advances but s->update_counter_ns does, and
the guest never makes forward progress.

The fix for this is to only advance update_counter_ns to the
timestamp of the last tick, not all the way to 'now'.  (This is the
pattern used in hw/misc/mps2-fpgaio.c's counter.)

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-id: 20230606134917.3782215-1-peter.maydell@linaro.org
(cherry picked from commit d2f9a79a8cf6ab992e1d0f27ad05b3e582d2b18a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 29191ea6a5203d26343d80238d1501cc15ba6b05
      
https://github.com/qemu/qemu/commit/29191ea6a5203d26343d80238d1501cc15ba6b05
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M include/qemu/compiler.h
    M include/qemu/host-utils.h

  Log Message:
  -----------
  host-utils: Avoid using __builtin_subcll on buggy versions of Apple Clang

We use __builtin_subcll() to do a 64-bit subtract with borrow-in and
borrow-out when the host compiler supports it.  Unfortunately some
versions of Apple Clang have a bug in their implementation of this
intrinsic which means it returns the wrong value.  The effect is that
a QEMU built with the affected compiler will hang when emulating x86
or m68k float80 division.

The upstream LLVM issue is:
https://github.com/llvm/llvm-project/issues/55253

The commit that introduced the bug apparently never made it into an
upstream LLVM release without the subsequent fix
https://github.com/llvm/llvm-project/commit/fffb6e6afdbaba563189c1f715058ed401fbc88d
but unfortunately it did make it into Apple Clang 14.0, as shipped
in Xcode 14.3 (14.2 is reported to be OK). The Apple bug number is
FB12210478.

Add ifdefs to avoid use of __builtin_subcll() on Apple Clang version
14 or greater.  There is not currently a version of Apple Clang which
has the bug fix -- when one appears we should be able to add an upper
bound to the ifdef condition so we can start using the builtin again.
We make the lower bound a conservative "any Apple clang with major
version 14 or greater" because the consequences of incorrectly
disabling the builtin when it would work are pretty small and the
consequences of not disabling it when we should are pretty bad.

Many thanks to those users who both reported this bug and also
did a lot of work in identifying the root cause; in particular
to Daniel Bertalan and osy.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1631
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1659
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel Bertalan <dani@danielbertalan.dev>
Tested-by: Tested-By: Solra Bizna <solra@bizna.name>
Message-id: 20230622130823.1631719-1-peter.maydell@linaro.org
(cherry picked from commit b0438861efe1dfbdfdd9fa1d9aa05100d37ea8ee)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 601f084ef7ac467228293e05ddc40217239dc61b
      
https://github.com/qemu/qemu/commit/601f084ef7ac467228293e05ddc40217239dc61b
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M pc-bios/keymaps/meson.build

  Log Message:
  -----------
  pc-bios/keymaps: Use the official xkb name for Arabic layout, not the legacy 
synonym

The xkb official name for the Arabic keyboard layout is 'ara'.
However xkb has for at least the past 15 years also permitted it to
be named via the legacy synonym 'ar'.  In xkeyboard-config 2.39 this
synoynm was removed, which breaks compilation of QEMU:

FAILED: pc-bios/keymaps/ar
/home/fred/qemu-git/src/qemu/build-full/qemu-keymap -f pc-bios/keymaps/ar -l ar
xkbcommon: ERROR: Couldn't find file "symbols/ar" in include paths
xkbcommon: ERROR: 1 include paths searched:
xkbcommon: ERROR:       /usr/share/X11/xkb
xkbcommon: ERROR: 3 include paths could not be added:
xkbcommon: ERROR:       /home/fred/.config/xkb
xkbcommon: ERROR:       /home/fred/.xkb
xkbcommon: ERROR:       /etc/xkb
xkbcommon: ERROR: Abandoning symbols file "(unnamed)"
xkbcommon: ERROR: Failed to compile xkb_symbols
xkbcommon: ERROR: Failed to compile keymap

The upstream xkeyboard-config change removing the compat
mapping is:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/470ad2cd8fea84d7210377161d86b31999bb5ea6

Make QEMU always ask for the 'ara' xkb layout, which should work on
both older and newer xkeyboard-config.  We leave the QEMU name for
this keyboard layout as 'ar'; it is not the only one where our name
for it deviates from the xkb standard name.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-id: 20230620162024.1132013-1-peter.maydell@linaro.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1709
(cherry picked from commit 497fad38979c16b6412388927401e577eba43d26)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 6331b12d6074b6f0f613226fd33849e684b7d4da
      
https://github.com/qemu/qemu/commit/6331b12d6074b6f0f613226fd33849e684b7d4da
  Author: Helge Deller <deller@gmx.de>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M hw/hppa/machine.c

  Log Message:
  -----------
  target/hppa: Fix OS reboot issues

When the OS triggers a reboot, the reset helper function sends a
qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET) together with an
EXCP_HLT exception to halt the CPUs.

So, at reboot when initializing the CPUs again, make sure to set all
instruction pointers to the firmware entry point, disable any interrupts,
disable data and instruction translations, enable PSW_Q bit  and tell qemu
to unhalt (halted=0) the CPUs again.

This fixes the various reboot issues which were seen when rebooting a
Linux VM, including the case where even the monarch CPU has been virtually
halted from the OS (e.g. via "chcpu -d 0" inside the Linux VM).

Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 50ba97e928b44ff5bc731c9ffe68d86acbe44639)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 51c48a919d364ce49b544bf8567256ce356d6c13
      
https://github.com/qemu/qemu/commit/51c48a919d364ce49b544bf8567256ce356d6c13
  Author: Helge Deller <deller@gmx.de>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M hw/hppa/machine.c

  Log Message:
  -----------
  target/hppa: Provide qemu version via fw_cfg to firmware

Give current QEMU version string to SeaBIOS-hppa via fw_cfg interface so
that the firmware can show the QEMU version in the boot menu info.

Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 069d296669448b9eef72c6332ae84af962d9582c)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 7b7474947fcf922a31368f17dfc24f59079342d1
      
https://github.com/qemu/qemu/commit/7b7474947fcf922a31368f17dfc24f59079342d1
  Author: Helge Deller <deller@gmx.de>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M pc-bios/hppa-firmware.img
    M roms/seabios-hppa

  Log Message:
  -----------
  target/hppa: New SeaBIOS-hppa version 7

Update SeaBIOS-hppa to version 7 which fixes a boot problem
with Debian-12 install CD images.

The problem with Debian-12 is, that the ramdisc got bigger
than what the firmware could load in one call to the LSI
scsi driver.

Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit bb9c998ca9343d445c76b69fa15dea9db692f526)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: pick this one before picking next 34ec3aea54368a92b6 "SeaBIOS-hppa 
version 8")


  Commit: b3a003c8907630e493e47d27e330059b43538c5a
      
https://github.com/qemu/qemu/commit/b3a003c8907630e493e47d27e330059b43538c5a
  Author: Helge Deller <deller@gmx.de>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M pc-bios/hppa-firmware.img
    M roms/seabios-hppa

  Log Message:
  -----------
  target/hppa: Update to SeaBIOS-hppa version 8

Update SeaBIOS-hppa to version 8.

Fixes:
- boot of HP-UX with SMP, and
- reboot of Linux and HP-UX with SMP

Enhancements:
- show qemu version in boot menu
- adds exit menu entry in boot menu to quit emulation
- allow to trace PCD_CHASSIS codes & machine run status

Signed-off-by: Helge Deller <deller@gmx.de>
(cherry picked from commit 34ec3aea54368a92b62a55c656335885ba8c65ef)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f3b7f02c3b85219d3e8fb9b2e8124f35424a4a75
      
https://github.com/qemu/qemu/commit/f3b7f02c3b85219d3e8fb9b2e8124f35424a4a75
  Author: Prasad Pandit <pjp@fedoraproject.org>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M hw/virtio/vhost.c

  Log Message:
  -----------
  vhost: release memory_listener object in error path

vhost_dev_start function does not release memory_listener object
in case of an error. This may crash the guest when vhost is unable
to set memory table:

  stack trace of thread 125653:
  Program terminated with signal SIGSEGV, Segmentation fault
  #0  memory_listener_register (qemu-kvm + 0x6cda0f)
  #1  vhost_dev_start (qemu-kvm + 0x699301)
  #2  vhost_net_start (qemu-kvm + 0x45b03f)
  #3  virtio_net_set_status (qemu-kvm + 0x665672)
  #4  qmp_set_link (qemu-kvm + 0x548fd5)
  #5  net_vhost_user_event (qemu-kvm + 0x552c45)
  #6  tcp_chr_connect (qemu-kvm + 0x88d473)
  #7  tcp_chr_new_client (qemu-kvm + 0x88cf83)
  #8  tcp_chr_accept (qemu-kvm + 0x88b429)
  #9  qio_net_listener_channel_func (qemu-kvm + 0x7ac07c)
  #10 g_main_context_dispatch (libglib-2.0.so.0 + 0x54e2f)

Release memory_listener objects in the error path.

Signed-off-by: Prasad Pandit <pjp@fedoraproject.org>
Message-Id: <20230529114333.31686-2-ppandit@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Fixes: c471ad0e9b ("vhost_net: device IOTLB support")
Cc: qemu-stable@nongnu.org
Acked-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1e3ffb34f764f8ac4c003b2b2e6a775b2b073a16)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: bc1a3a177482fada68c08efcc9580b01fa1c7a45
      
https://github.com/qemu/qemu/commit/bc1a3a177482fada68c08efcc9580b01fa1c7a45
  Author: Eugenio Pérez <eperezma@redhat.com>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M net/vhost-vdpa.c

  Log Message:
  -----------
  vdpa: fix not using CVQ buffer in case of error

Bug introducing when refactoring.  Otherway, the guest never received
the used buffer.

Fixes: be4278b65fc1 ("vdpa: extract vhost_vdpa_net_cvq_add from 
vhost_vdpa_net_handle_ctrl_avail")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230602173451.1917999-1-eperezma@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
(cherry picked from commit d45243bcfc61a3c34f96a4fc34bffcb9929daba0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 3d12598b74ed4bcc6db8b50818a95c4b770d4487
      
https://github.com/qemu/qemu/commit/3d12598b74ed4bcc6db8b50818a95c4b770d4487
  Author: Ani Sinha <anisinha@redhat.com>
  Date:   2023-06-26 (Mon, 26 Jun 2023)

  Changed paths:
    M net/vhost-vdpa.c

  Log Message:
  -----------
  vhost-vdpa: do not cleanup the vdpa/vhost-net structures if peer nic is 
present

When a peer nic is still attached to the vdpa backend, it is too early to free
up the vhost-net and vdpa structures. If these structures are freed here, then
QEMU crashes when the guest is being shut down. The following call chain
would result in an assertion failure since the pointer returned from
vhost_vdpa_get_vhost_net() would be NULL:

do_vm_stop() -> vm_state_notify() -> virtio_set_status() ->
virtio_net_vhost_status() -> get_vhost_net().

Therefore, we defer freeing up the structures until at guest shutdown
time when qemu_cleanup() calls net_cleanup() which then calls
qemu_del_net_client() which would eventually call vhost_vdpa_cleanup()
again to free up the structures. This time, the loop in net_cleanup()
ensures that vhost_vdpa_cleanup() will be called one last time when
all the peer nics are detached and freed.

All unit tests pass with this change.

CC: imammedo@redhat.com
CC: jusual@redhat.com
CC: mst@redhat.com
Fixes: CVE-2023-3301
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128929
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Message-Id: <20230619065209.442185-1-anisinha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a0d7215e339b61c7d7a7b3fcf754954d80d93eb8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context change for stable-7.2)


  Commit: 44acbc773659a39ba9aecdaf39441ad369d2f596
      
https://github.com/qemu/qemu/commit/44acbc773659a39ba9aecdaf39441ad369d2f596
  Author: Vivek Kasireddy <vivek.kasireddy@intel.com>
  Date:   2023-06-28 (Wed, 28 Jun 2023)

  Changed paths:
    M hw/display/virtio-gpu.c

  Log Message:
  -----------
  virtio-gpu: Make non-gl display updates work again when blob=true

In the case where the console does not have gl capability, and
if blob is set to true, make sure that the display updates still
work. Commit e86a93f55463 accidentally broke this by misplacing
the return statement (in resource_flush) causing the updates to
be silently ignored.

Fixes: e86a93f55463 ("virtio-gpu: splitting one extended mode guest fb into 
n-scanouts")
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20230623060454.3749910-1-vivek.kasireddy@intel.com>
(cherry picked from commit 34e29d85a7734802317c4cac9ad52b10d461c1dc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: f8e3b3290c83c20ed873e5d289c8d2c7f6f46fd3
      
https://github.com/qemu/qemu/commit/f8e3b3290c83c20ed873e5d289c8d2c7f6f46fd3
  Author: Nicholas Piggin <npiggin@gmail.com>
  Date:   2023-06-29 (Thu, 29 Jun 2023)

  Changed paths:
    M softmmu/icount.c

  Log Message:
  -----------
  icount: don't adjust virtual time backwards after warp

The icount-based QEMU_CLOCK_VIRTUAL runs ahead of the RT clock at times.
When warping, it is possible it is still ahead at the end of the warp,
which causes icount adaptive mode to adjust it backward. This can result
in the machine observing time going backwards.

Prevent this by clamping adaptive adjustment to 0 at minimum.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20230627061406.241847-1-npiggin@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 67f85346ca9305d9fb3254ceff735ceaadeb0911)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/10fad73a2bf1...f8e3b3290c83



reply via email to

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