Branch: refs/heads/staging-10.1
  Home:   https://github.com/qemu/qemu
  Commit: dfae27159d00de9259f95cf578784cfccb56ce04
      
https://github.com/qemu/qemu/commit/dfae27159d00de9259f95cf578784cfccb56ce04
  Author: Peter Maydell <[email protected]>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M hw/usb/hcd-uhci.c

  Log Message:
  -----------
  hw/usb/hcd-uhci: don't assert for SETUP to non-0 endpoint

If the guest feeds invalid data to the UHCI controller, we
can assert:
qemu-system-x86_64: ../../hw/usb/core.c:744: usb_ep_get: Assertion `pid == 
USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed.

(see issue 2548 for the repro case).  This happens because the guest
attempts USB_TOKEN_SETUP to an endpoint other than 0, which is not
valid.  The controller code doesn't catch this guest error, so
instead we hit the assertion in the USB core code.

Catch the case of SETUP to non-zero endpoint, and treat it as a fatal
error in the TD, in the same way we do for an invalid PID value in
the TD.

This is the UHCI equivalent of the same bug in OHCI that we fixed in
commit 3c3c233677 ("hw/usb/hcd-ohci: Fix #1510, #303: pid not IN or
OUT").

This bug has been tracked as CVE-2024-8354.

Cc: [email protected]
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2548
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
(cherry picked from commit d0af3cd0274e265435170a583c72b9f0a4100dff)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 2d1b1bad05ddce25b1dbc05cdc05a229c64f72a8
      
https://github.com/qemu/qemu/commit/2d1b1bad05ddce25b1dbc05cdc05a229c64f72a8
  Author: Laurent Vivier <[email protected]>
  Date:   2025-09-27 (Sat, 27 Sep 2025)

  Changed paths:
    M meson.build

  Log Message:
  -----------
  net/passt: Fix build failure due to missing GIO dependency

The passt networking backend uses functions from the GIO library,
such as g_subprocess_launcher_new(), to manage its daemon process.
So, building with passt enabled requires GIO to be available.

If we enable passt and disable gio the build fails during linkage with
undefined reference errors:

  /usr/bin/ld: libsystem.a.p/net_passt.c.o: in function 
`net_passt_start_daemon':
  net/passt.c:250: undefined reference to `g_subprocess_launcher_new'
  /usr/bin/ld: net/passt.c:251: undefined reference to 
`g_subprocess_launcher_take_fd'
  /usr/bin/ld: net/passt.c:253: undefined reference to 
`g_subprocess_launcher_spawnv'
  /usr/bin/ld: net/passt.c:256: undefined reference to `g_object_unref'
  /usr/bin/ld: net/passt.c:263: undefined reference to `g_subprocess_wait'
  /usr/bin/ld: net/passt.c:268: undefined reference to 
`g_subprocess_get_if_exited'
  /usr/bin/ld: libsystem.a.p/net_passt.c.o: in function 
`glib_autoptr_clear_GSubprocess':
  /usr/include/glib-2.0/gio/gio-autocleanups.h:132: undefined reference to 
`g_object_unref'
  /usr/bin/ld: libsystem.a.p/net_passt.c.o: in function 
`net_passt_start_daemon':
  net/passt.c:269: undefined reference to `g_subprocess_get_exit_status'

Fix this by adding an explicit weson dependency on GIO for the passt
option.
The existing dependency on linux is kept because passt is only available
on this OS.

Cc: [email protected]
Fixes: 854ee02b222 ("net: Add passt network backend")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3121
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 4ccca2cc05a2d904d1e25365accf3bcbe553c8b0)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: f906aa2e333bfb652d254ab0f9cb9cebdfccb0ae
      
https://github.com/qemu/qemu/commit/f906aa2e333bfb652d254ab0f9cb9cebdfccb0ae
  Author: Fabian Vogt <[email protected]>
  Date:   2025-09-29 (Mon, 29 Sep 2025)

  Changed paths:
    M hw/intc/xics.c

  Log Message:
  -----------
  hw/intc/xics: Add missing call to register vmstate_icp_server

An obsolete wrapper function with a workaround was removed entirely,
without restoring the call it wrapped.

Without this, the guest is stuck after savevm/loadvm.

Fixes: 24ee9229fe31 ("ppc/spapr: remove deprecated machine pseries-2.9")
Signed-off-by: Fabian Vogt <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link: https://lore.kernel.org/qemu-devel/6187781.lOV4Wx5bFT@fvogt-thinkpad
Signed-off-by: Fabiano Rosas <[email protected]>
Reviewed-by: Gautam Menghani <[email protected]>
Signed-off-by: Harsh Prateek Bora <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Message-ID: <[email protected]>
(cherry picked from commit f5738aedc21790bd07dbead6b6272a605d5c1138)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e60467febb406b70b0a4e8cd05c4172a6c5d99ed
      
https://github.com/qemu/qemu/commit/e60467febb406b70b0a4e8cd05c4172a6c5d99ed
  Author: Harsh Prateek Bora <[email protected]>
  Date:   2025-09-29 (Mon, 29 Sep 2025)

  Changed paths:
    M hw/ppc/spapr.c

  Log Message:
  -----------
  ppc/spapr: init lrdr-capapcity phys with ram size if maxmem not provided

lrdr-capacity contains phys field which communicates the maximum address
in bytes and therefore, the most memory that can be allocated to this
partition. This is usually populated when maxmem is provided alongwith
memory size on qemu command line. However since maxmem is an optional
param, this leads to bits being set to 0 in absence of maxmem param.
Fix this by initializing the respective bits as per total mem size in
such case.

Reported-by: Gaurav Batra <[email protected]>
Tested-by: David Christensen <[email protected]>
Signed-off-by: Harsh Prateek Bora <[email protected]>
Reviewed-by: Shivaprasad G Bhat <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Message-ID: <[email protected]>
(cherry picked from commit 6285eebd3a5fea018eb51d696b51079f44dd1eb3)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: daa07cbe017407fa43dccb33dd122fa9ab0f94f4
      
https://github.com/qemu/qemu/commit/daa07cbe017407fa43dccb33dd122fa9ab0f94f4
  Author: Mohamed Akram <[email protected]>
  Date:   2025-10-01 (Wed, 01 Oct 2025)

  Changed paths:
    M ui/spice-core.c

  Log Message:
  -----------
  ui/spice: Fix abort on macOS

The check is faulty because the thread variable was assigned in the main
thread while the main loop runs in a different thread on macOS.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3070
Signed-off-by: Mohamed Akram <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e7ecb533ee0dbfbe30c90abb213247f4943a9a12)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ecc1aef81eafa53b7267fb4d93aaf2eb6a1e3d5a
      
https://github.com/qemu/qemu/commit/ecc1aef81eafa53b7267fb4d93aaf2eb6a1e3d5a
  Author: Marc-André Lureau <[email protected]>
  Date:   2025-10-01 (Wed, 01 Oct 2025)

  Changed paths:
    M ui/spice-display.c

  Log Message:
  -----------
  ui/spice: fix crash when disabling GL scanout on

When spice_qxl_gl_scanout2() isn't available, the fallback code
incorrectly handles NULL arguments to disable the scanout, leading to:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  spice_server_gl_scanout (qxl=0x55a25ce57ae8, fd=0x0, width=0, height=0, 
offset=0x0, stride=0x0, num_planes=0, format=0, modifier=72057594037927935, 
y_0_top=0)
    at ../ui/spice-display.c:983
983         if (num_planes <= 1) {

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2391334
Fixes: 98a050ca93afd8 ("ui/spice: support multi plane dmabuf scanout")
Signed-off-by: Marc-André Lureau <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 62fd247a24290dba2b2de4ee8575624a7993973c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: f3b84ec247cfe8e4d883feb5e85bc7392ff1a7c9
      
https://github.com/qemu/qemu/commit/f3b84ec247cfe8e4d883feb5e85bc7392ff1a7c9
  Author: Thomas Huth <[email protected]>
  Date:   2025-10-01 (Wed, 01 Oct 2025)

  Changed paths:
    M ui/icons/qemu.svg

  Log Message:
  -----------
  ui/icons/qemu.svg: Add metadata information (author, license) to the logo

We've got two versions of the QEMU logo in the repository, one with
the whole word "QEMU" (pc-bios/qemu_logo.svg) and one that only contains
the letter "Q" (ui/icons/qemu.svg). While qemu_logo.svg contains the
proper metadata with license and author information, this is missing
from the ui/icons/qemu.svg file. Copy the meta data there so that
people have a chance to know the license of the file if they only
look at the qemu.svg file.

Closes: https://gitlab.com/qemu-project/qemu/-/issues/3139
Signed-off-by: Thomas Huth <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 9163424c50981dbc4ded9990228ac01a3b193656)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e93d2c5fdd151241ace5090bb4a2d381626ee4bf
      
https://github.com/qemu/qemu/commit/e93d2c5fdd151241ace5090bb4a2d381626ee4bf
  Author: Andrew Jones <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M hw/riscv/riscv-iommu.c

  Log Message:
  -----------
  hw/riscv/riscv-iommu: Fix MSI table size limit

The MSI table is not limited to 4k. The only constraint the table has
is that its base address must be aligned to its size, ensuring no
offsets of the table size will overrun when added to the base address
(see "8.5. MSI page tables" of the AIA spec).

Fixes: 0c54acb8243d ("hw/riscv: add RISC-V IOMMU base emulation")
Signed-off-by: Andrew Jones <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 4f7528295b3e6dfe1189f660fa7865ad972d82e7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c25be2649cb9be3dcf16d11d7a0c8bbaf2790d21
      
https://github.com/qemu/qemu/commit/c25be2649cb9be3dcf16d11d7a0c8bbaf2790d21
  Author: Andrea Bolognani <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M docs/interop/firmware.json

  Log Message:
  -----------
  docs/interop/firmware: Add riscv64 to FirmwareArchitecture

Descriptors using this value have been shipped for years
by distros, so we just need to update the spec to match
reality.

Signed-off-by: Andrea Bolognani <[email protected]>
Reviewed-by: Kashyap Chamarthy <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit da14767b356c2342197708a997eeb0da053262a0)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 0be25ffa79bb4478f2933ddd75bff8c528550ea3
      
https://github.com/qemu/qemu/commit/0be25ffa79bb4478f2933ddd75bff8c528550ea3
  Author: Frank Chang <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M hw/char/sifive_uart.c

  Log Message:
  -----------
  hw/char: sifive_uart: Raise IRQ according to the Tx/Rx watermark thresholds

Currently, the SiFive UART raises an IRQ whenever:

  1. ie.txwm is enabled.
  2. ie.rxwm is enabled and the Rx FIFO is not empty.

It does not check the watermark thresholds set by software. However,
since commit [1] changed the SiFive UART character printing from
synchronous to asynchronous, Tx overflows may occur, causing characters
to be dropped when running Linux because:

  1. The Linux SiFive UART driver sets the transmit watermark level to 1
     [2], meaning a transmit watermark interrupt is raised whenever a
     character is enqueued into the Tx FIFO.
  2. Upon receiving a transmit watermark interrupt, the Linux driver
     transfers up to a full Tx FIFO's worth of characters from the Linux
     serial transmit buffer [3], without checking the txdata.full flag
     before transferring multiple characters [4].

To fix this issue, we must honor the Tx/Rx watermark thresholds and
raise interrupts only when the Tx threshold is exceeded or the Rx
threshold is undercut.

[1] 53c1557b230986ab6320a58e1b2c26216ecd86d5
[2] 
https://github.com/torvalds/linux/blob/master/drivers/tty/serial/sifive.c#L1039
[3] 
https://github.com/torvalds/linux/blob/master/drivers/tty/serial/sifive.c#L538
[4] 
https://github.com/torvalds/linux/blob/master/drivers/tty/serial/sifive.c#L291

Signed-off-by: Frank Chang <[email protected]>
Signed-off-by: Emmanuel Blot <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 191df346175283af013f414375f4be59fb850120)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 7c7694d73cee63c98c77b9b1db902131ba5535fc
      
https://github.com/qemu/qemu/commit/7c7694d73cee63c98c77b9b1db902131ba5535fc
  Author: stove <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M target/riscv/cpu.h

  Log Message:
  -----------
  target/riscv: use riscv_csrr in riscv_csr_read

Commit 38c83e8d3a33 ("target/riscv: raise an exception when CSRRS/CSRRC
writes a read-only CSR") changed the behavior of riscv_csrrw, which
would formerly be treated as read-only if the write mask were set to 0.

Fixes an exception being raised when accessing read-only vector CSRs
like vtype.

Fixes: 38c83e8d3a33 ("target/riscv: raise an exception when CSRRS/CSRRC writes 
a read-only CSR")

Signed-off-by: stove <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit cebaf7434b4af059caca053ee1ec7ed8df91c2a7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c65d1a6b1309e222840ef6d4944ec09ab370c3a4
      
https://github.com/qemu/qemu/commit/c65d1a6b1309e222840ef6d4944ec09ab370c3a4
  Author: Vladimir Isaev <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M target/riscv/translate.c

  Log Message:
  -----------
  target/riscv: do not use translator_ldl in opcode_at

opcode_at is used only in semihosting checks to match opcodes with expected
pattern.

This is not a translator and if we got following assert if page is not in TLB:
qemu-system-riscv64: ../accel/tcg/translator.c:363: record_save: Assertion
`offset == db->record_start + db->record_len' failed.

Fixes: 1f9c4462334f ("target/riscv: Use translator_ld* for everything")
Signed-off-by: Vladimir Isaev <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
[ Changes by AF:
 - Fixup header includes after rebase
]
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit a86d3352ab70f33f5feabbf9bad9450d3c19d0bf)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: b01f2eccf2496fd1f97139f44aaa93340f7bfd6c
      
https://github.com/qemu/qemu/commit/b01f2eccf2496fd1f97139f44aaa93340f7bfd6c
  Author: Guo Ren (Alibaba DAMO Academy) <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M hw/riscv/riscv-iommu.c

  Log Message:
  -----------
  hw/riscv/riscv-iommu: Fixup PDT Nested Walk

Current implementation is wrong when iohgatp != bare. The RISC-V
IOMMU specification has defined that the PDT is based on GPA, not
SPA. So this patch fixes the problem, making PDT walk correctly
when the G-stage table walk is enabled.

Fixes: 0c54acb8243d ("hw/riscv: add RISC-V IOMMU base emulation")
Cc: [email protected]
Cc: Sebastien Boeuf <[email protected]>
Cc: Tomasz Jeznach <[email protected]>
Reviewed-by: Weiwei Li <[email protected]>
Reviewed-by: Nutty Liu <[email protected]>
Signed-off-by: Guo Ren (Alibaba DAMO Academy) <[email protected]>
Tested-by: Chen Pei <[email protected]>
Tested-by: Fangyu Yu <[email protected]>
Message-ID: <[email protected]>
[ Changes by AF:
 - Add braces to if statements
]
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 15abfced803929f935bb59a0e1b02558bd8325c4)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: e3641f4ecfafa71285c80dea04a000e71dab8946
      
https://github.com/qemu/qemu/commit/e3641f4ecfafa71285c80dea04a000e71dab8946
  Author: vhaudiquet <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M target/riscv/insn_trans/trans_rvzce.c.inc

  Log Message:
  -----------
  target/riscv: Fix endianness swap on compressed instructions

Three instructions were not using the endianness swap flag, which resulted in a 
bug on big-endian architectures.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3131
Buglink: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2123828

Fixes: e0a3054f18e ("target/riscv: add support for Zcb extension")
Signed-off-by: Valentin Haudiquet <[email protected]>
Cc: [email protected]
Reviewed-by: Anton Johansson <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit b25133d38fe693589cf695b85968caa0724bfafd)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 8650b5597a9d568f0d005d4d0caf13e333c44a04
      
https://github.com/qemu/qemu/commit/8650b5597a9d568f0d005d4d0caf13e333c44a04
  Author: Max Chou <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M target/riscv/cpu.c
    M target/riscv/csr.c
    M target/riscv/machine.c
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: rvv: Replace checking V by checking Zve32x

The Zve32x extension will be applied by the V and Zve* extensions.
Therefore we can replace the original V checking with Zve32x checking for both
the V and Zve* extensions.

Signed-off-by: Max Chou <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit ae4a37f57818e47e212272821a5a86ad54620eb8)
(Mjt: drop the MonitorDef change due to missing v10.1.0-850-ge06d209aa6 
"target/riscv: implement MonitorDef HMP API")
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d7f661905b38beebd0779d45a53cc513ba744395
      
https://github.com/qemu/qemu/commit/d7f661905b38beebd0779d45a53cc513ba744395
  Author: Max Chou <[email protected]>
  Date:   2025-10-04 (Sat, 04 Oct 2025)

  Changed paths:
    M target/riscv/tcg/tcg-cpu.c

  Log Message:
  -----------
  target/riscv: rvv: Modify minimum VLEN according to enabled vector extensions

According to the RISC-V unprivileged specification, the VLEN should be greater
or equal to the ELEN. This commit modifies the minimum VLEN based on the vector
extensions and introduces a check rule for VLEN and ELEN.

  Extension     Minimum VLEN
* V                      128
* Zve64[d|f|x]            64
* Zve32[f|x]              32

Signed-off-by: Max Chou <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit be50ff3a73859ebbbdc0e6f704793062b1743d93)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 109f336448e7fa09f3aee6e1dab2648e2a2d4568
      
https://github.com/qemu/qemu/commit/109f336448e7fa09f3aee6e1dab2648e2a2d4568
  Author: Juraj Marcin <[email protected]>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M migration/migration.c

  Log Message:
  -----------
  migration: Fix state transition in postcopy_start() error handling

Commit 48814111366b ("migration: Always set DEVICE state") introduced
DEVICE state to postcopy, which moved the actual state transition that
leads to POSTCOPY_ACTIVE.

However, the error handling part of the postcopy_start() function still
expects the state POSTCOPY_ACTIVE, but depending on where an error
happens, now the state can be either ACTIVE, DEVICE or CANCELLING, but
never POSTCOPY_ACTIVE, as this transition now happens just before a
successful return from the function.

Instead, accept any state except CANCELLING when transitioning to FAILED
state.

Cc: [email protected]
Fixes: 48814111366b ("migration: Always set DEVICE state")
Signed-off-by: Juraj Marcin <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 725a9e5f7885a3c0d0cd82022d6eb5a758ac9d47)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 977ffc7abcb06568773c724f6cd7aab48d2e490e
      
https://github.com/qemu/qemu/commit/977ffc7abcb06568773c724f6cd7aab48d2e490e
  Author: Peter Maydell <[email protected]>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M include/system/memory.h

  Log Message:
  -----------
  include/system/memory.h: Clarify address_space_destroy() behaviour

address_space_destroy() doesn't actually immediately destroy the AS;
it queues it to be destroyed via RCU. This means you can't g_free()
the memory the AS struct is in until that has happened.

Clarify this in the documentation.

Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 9e7bfda4909cc688dd0327e17985019f08a78d5d)
(Mjt: this is just a comment fix, but it makes subsequent changes to apply c
leanly)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ded5c6245446ee8305fe01e2471af5b02b4be3d3
      
https://github.com/qemu/qemu/commit/ded5c6245446ee8305fe01e2471af5b02b4be3d3
  Author: Peter Xu <[email protected]>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M include/system/memory.h
    M system/memory.c

  Log Message:
  -----------
  memory: New AS helper to serialize destroy+free

If an AddressSpace has been created in its own allocated
memory, cleaning it up requires first destroying the AS
and then freeing the memory. Doing this doesn't work:

    address_space_destroy(as);
    g_free_rcu(as, rcu);

because both address_space_destroy() and g_free_rcu()
try to use the same 'rcu' node in the AddressSpace struct
and the address_space_destroy hook gets overwritten.

Provide a new address_space_destroy_free() function which
will destroy the AS and then free the memory it uses, all
in one RCU callback.

(CC to stable because the next commit needs this function.)

Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 041600e23f2fe2a9c252c9a8b26c7d147bedf982)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 7bd98c65e0ef871c7fe66e42a8c0b01784da1828
      
https://github.com/qemu/qemu/commit/7bd98c65e0ef871c7fe66e42a8c0b01784da1828
  Author: Peter Maydell <[email protected]>
  Date:   2025-10-05 (Sun, 05 Oct 2025)

  Changed paths:
    M hw/core/cpu-common.c
    M include/exec/cpu-common.h
    M include/hw/core/cpu.h
    A stubs/cpu-destroy-address-spaces.c
    M stubs/meson.build
    M system/physmem.c

  Log Message:
  -----------
  physmem: Destroy all CPU AddressSpaces on unrealize

When we unrealize a CPU object (which happens on vCPU hot-unplug), we
should destroy all the AddressSpace objects we created via calls to
cpu_address_space_init() when the CPU was realized.

Commit 24bec42f3d6eae added a function to do this for a specific
AddressSpace, but did not add any places where the function was
called.

Since we always want to destroy all the AddressSpaces on unrealize,
regardless of the target architecture, we don't need to try to keep
track of how many are still undestroyed, or make the target
architecture code manually call a destroy function for each AS it
created.  Instead we can adjust the function to always completely
destroy the whole cpu->ases array, and arrange for it to be called
during CPU unrealize as part of the common code.

Without this fix, AddressSanitizer will report a leak like this
from a run where we hot-plugged and then hot-unplugged an x86 KVM
vCPU:

Direct leak of 416 byte(s) in 1 object(s) allocated from:
    #0 0x5b638565053d in calloc 
(/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/qemu-system-x86_64+0x1ee153d)
 (BuildId: c1cd6022b195142106e1bffeca23498c2b752bca)
    #1 0x7c28083f77b1 in g_malloc0 
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x637b1) (BuildId: 
1eb6131419edb83b2178b682829a6913cf682d75)
    #2 0x5b6386999c7c in cpu_address_space_init 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../system/physmem.c:797:25
    #3 0x5b638727f049 in kvm_cpu_realizefn 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/kvm/kvm-cpu.c:102:5
    #4 0x5b6385745f40 in accel_cpu_common_realize 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../accel/accel-common.c:101:13
    #5 0x5b638568fe3c in cpu_exec_realizefn 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/cpu-common.c:232:10
    #6 0x5b63874a2cd5 in x86_cpu_realizefn 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/cpu.c:9321:5
    #7 0x5b6387a0469a in device_set_realized 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:494:13
    #8 0x5b6387a27d9e in property_set_bool 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:2375:5
    #9 0x5b6387a2090b in object_property_set 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1450:5
    #10 0x5b6387a35b05 in object_property_set_qobject 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/qom-qobject.c:28:10
    #11 0x5b6387a21739 in object_property_set_bool 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1520:15
    #12 0x5b63879fe510 in qdev_realize 
/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:276:12

Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2517
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 300a87c502c4ba7ffc7720d8f3583e3d1a68348a)
Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/562020faa2ee...7bd98c65e0ef

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications

Reply via email to