MicroBlaze CPU model has a "little-endian" property, pointing to
the @endi internal field. Commit c36ec3a9655 ("hw/microblaze:
Explicit CPU endianness") took care of having all MicroBlaze
boards with an explicit default endianness, so later commit 415aae543ed ("target/microblaze: Consider endianness while
translating code") could infer the endianness at runtime from
the @endi field, and not a compile time via the TARGET_BIG_ENDIAN
definition. Doing so, we forgot to make the endianness explicit
on user emulation, so there all CPUs are started with the default
"little-endian=off" value, leading to breaking support for little
endian binaries:
Fix by restoring the previous behavior of starting with the
builtin endianness of the binary:
$ qemu-microblazeel ./hello-world-mbel
Hello World
Cc: qemu-stable@nongnu.org Fixes: 415aae543ed ("target/microblaze: Consider endianness while translating code") Reported-by: Edgar E. Iglesias <edgar.iglesias@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com>
Message-Id: <20251006173350.17455-1-philmd@linaro.org>
(cherry picked from commit 91fc6d8101de97c588e0a4263cf4f6148b3e702a)
(Mjt: adapt for missing v10.1.0-38-gaf880af8d4
"linux-user: Move get_elf_cpu_model to target/elfload.c") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For the fmpyadd instruction on the hppa architecture, there is a bit
used to specify whether the instruction is operating on a 32 bit or
64 bit floating point register. For most instructions, such a bit is 0
when operating on the smaller register and 1 when operating on the
larger register. However, according to page 6-57 of the PA-RISC 1.1
Architecture and Instruction Set Reference Manual, this convention is
reversed for the fmpyadd instruction specifically, meaning the bit is
1 for operations on 32 bit registers and 0 for 64 bit registers. See
also page 6-18 (fig. 6-8) and 6-19 (table 6-16), where the f field
for FMPYADD and FMPYSUB is documented. Previously, QEMU decoded this
operation as operating on the other size of register, leading to bugs
when translating the fmpyadd instruction. This patch fixes that issue.
Reported-by: Andreas Hüttel <andreas.huettel@ur.de> Signed-off-by: Gabriel Brookman <brookmangabriel@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3096 Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Helge Deller <deller@gmx.de>
Message-ID: <20251009-hppa-correct-fmpyadd-size-bit-decoding-v1-1-f63bb6c3290c@gmail.com>
[PMD: Add documentation refs mentioned by Andreas K. Huettel] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit cea82f8cdd07697a48ae1c4e026707463f432a45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 13 Oct 2025 16:34:28 +0000 (18:34 +0200)]
target/i386: user: do not set up a valid LDT on reset
In user-mode emulation, QEMU uses the default setting of the LDT base
and limit, which places it at the bottom 64K of virtual address space.
However, by default there is no LDT at all in Linux processes, and
therefore the limit should be 0.
This is visible as a NULL pointer dereference in LSL and LAR instructions
when they try to read the LDT at an unmapped address.
Resolves: #1376 Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 58aa1d08bbc406ba3982f32ffb1bef0ff4f8f369) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 13 Oct 2025 16:24:54 +0000 (18:24 +0200)]
async: access bottom half flags with qatomic_read
Running test-aio-multithread under TSAN reveals data races on bh->flags.
Because bottom halves may be scheduled or canceled asynchronously,
without taking a lock, adjust aio_compute_bh_timeout() and aio_ctx_check()
to use a relaxed read to access the flags.
Use an acquire load to ensure that anything that was written prior to
qemu_bh_schedule() is visible.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2749 Closes: https://gitlab.com/qemu-project/qemu/-/issues/851 Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5142397c79330aab9bef3230991c8ac0c251110f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
i386/tcg/smm_helper: Properly apply DR values on SMM entry / exit
do_smm_enter and helper_rsm sets the env->dr, but does not sync the
values with cpu_x86_update_dr7. A malicious kernel may control the
instruction pointer in SMM by setting a breakpoint on the SMI
entry point, and after do_smm_enter cpu->breakpoints contains the
stale breakpoint; and because IDT is not reloaded upon SMI entry,
the debug exception handler controlled by the malicious kernel
is invoked.
A different sequence, SMI INIT SIPI, is also buggy in TCG because
INIT is not blocked or latched during SMM. However, it is not
vulnerable to an instruction pointer control in the same way because
x86_cpu_exec_reset clears env->hflags, exiting SMM.
Fixes: a9bad65d2c1f ("target-i386: wake up processors that receive an SMI") Analyzed-by: YiFei Zhu <zhuyifei@google.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit df32e5c568c9cf68c15a9bbd98d0c3aff19eab63) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jon Kohler [Wed, 8 Oct 2025 20:25:57 +0000 (13:25 -0700)]
i386/kvm: Expose ARCH_CAP_FB_CLEAR when invulnerable to MDS
Newer Intel hardware (Sapphire Rapids and higher) sets multiple MDS
immunity bits in MSR_IA32_ARCH_CAPABILITIES but lacks the hardware-level
MSR_ARCH_CAP_FB_CLEAR (bit 17):
ARCH_CAP_MDS_NO
ARCH_CAP_TAA_NO
ARCH_CAP_PSDP_NO
ARCH_CAP_FBSDP_NO
ARCH_CAP_SBDR_SSDP_NO
This prevents VMs with fb-clear=on from migrating from older hardware
(Cascade Lake, Ice Lake) to newer hardware, limiting live migration
capabilities. Note fb-clear was first introduced in v8.1.0 [1].
Expose MSR_ARCH_CAP_FB_CLEAR for MDS-invulnerable systems to enable
seamless migration between hardware generations.
Note: There is no impact when a guest migrates to newer hardware as
the existing bit combinations already mark the host as MMIO-immune and
disable FB_CLEAR operations in the kernel (see Linux's
arch_cap_mmio_immune() and vmx_update_fb_clear_dis()). See kernel side
discussion for [2] for additional context.
[1] 22e1094ca82 ("target/i386: add support for FB_CLEAR feature")
[2] https://patchwork.kernel.org/project/kvm/patch/20250401044931.793203-1-jon@nutanix.com/
Mathias Krause [Thu, 12 Jun 2025 14:21:55 +0000 (16:21 +0200)]
target/i386: Fix CR2 handling for non-canonical addresses
Commit 3563362ddfae ("target/i386: Introduce structures for mmu_translate")
accidentally modified CR2 for non-canonical address exceptions while these
should lead to a #GP / #SS instead -- without changing CR2.
block/curl.c: Use explicit long constants in curl_easy_setopt calls
curl_easy_setopt takes a variable argument that depends on what
CURLOPT you are setting. Some require a long constant. Passing a
plain int constant is potentially wrong on some platforms.
With warnings enabled, multiple warnings like this were printed:
../block/curl.c: In function ‘curl_init_state’:
../block/curl.c:474:13: warning: call to ‘_curl_easy_setopt_err_long’ declared with attribute warning: curl_easy_setopt expects a long argument [-Wattribute-warning]
474 | curl_easy_setopt(state->curl, CURLOPT_AUTOREFERER, 1) ||
| ^
Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Chenxi Mao <maochenxi@bosc.ac.cn> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20251009141026.4042021-2-rjones@redhat.com>
(cherry picked from commit ed26056d90ddff21351f3efd2cb47fea4f0e1d45) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Damien Bergamini [Fri, 10 Oct 2025 04:55:55 +0000 (13:55 +0900)]
pcie_sriov: Fix broken MMIO accesses from SR-IOV VFs
Starting with commit cab1398a60eb, SR-IOV VFs are realized as soon as
pcie_sriov_pf_init() is called. Because pcie_sriov_pf_init() must be
called before pcie_sriov_pf_init_vf_bar(), the VF BARs types won't be
known when the VF realize function calls pcie_sriov_vf_register_bar().
This breaks the memory regions of the VFs (for instance with igbvf):
$ lspci
...
Region 0: Memory at 281a00000 (64-bit, prefetchable) [virtual] [size=16K]
Region 3: Memory at 281a20000 (64-bit, prefetchable) [virtual] [size=16K]
Max Chou [Fri, 24 Jan 2025 07:33:22 +0000 (15:33 +0800)]
target/riscv: rvv: Fix vslide1[up|down].vx unexpected result when XLEN=32 and SEW=64
When XLEN is 32 and SEW is 64, the original implementation of
vslide1up.vx and vslide1down.vx helper functions fills the 32-bit value
of rs1 into the first element of the destination vector register (rd),
which is a 64-bit element.
This commit attempted to resolve the issue by extending the rs1 value
to 64 bits during the TCG translation phase to ensure that the helper
functions won't lost the higer 32 bits.
Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250124073325.2467664-1-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 81d1885dcc4424fec6761120f6e251eb3408fb8e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jim Shu [Wed, 24 Sep 2025 07:48:18 +0000 (15:48 +0800)]
target/riscv: Fix ssamoswap error handling
Follow the RISC-V CFI v1.0 spec [1] to fix the exception type
when ssamoswap is disabled by xSSE.
[1] RISC-V CFI spec v1.0, ch2.7 Atomic Swap from a Shadow Stack Location
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250924074818.230010-4-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 0b16c7b6a854d461cdfd418769b51d58e43dd92a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jim Shu [Wed, 24 Sep 2025 07:48:17 +0000 (15:48 +0800)]
target/riscv: Fix SSP CSR error handling in VU/VS mode
In VU/VS mode, accessing $ssp CSR will trigger the virtual instruction
exception instead of illegal instruction exception if SSE is disabled
via xenvcfg CSRs.
This is from RISC-V CFI v1.0 spec ch2.2.4. Shadow Stack Pointer
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250924074818.230010-3-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 84c1605b7606d810ded4c1c3a2717f158dc89e3f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Jim Shu [Wed, 24 Sep 2025 07:48:16 +0000 (15:48 +0800)]
target/riscv: Fix the mepc when sspopchk triggers the exception
When sspopchk is in the middle of TB and triggers the SW check
exception, it should update PC from gen_update_pc(). If not, RISC-V mepc
CSR will get wrong PC address which is still at the start of TB.
Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250924074818.230010-2-jim.shu@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit c851052a77fd79300708df2070297b5428b4be8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 25 Sep 2025 11:57:23 +0000 (12:57 +0100)]
target/arm: Don't set HCR.RW for AArch32 only CPUs
In commit 39ec3fc0301 we fixed a bug where we were not implementing
HCR_EL2.RW as RAO/WI for CPUs where EL1 doesn't support AArch32.
However, we got the condition wrong, so we now set this bit even on
CPUs which have no AArch64 support at all. This is wrong because the
AArch32 HCR register defines this bit as RES0.
Correct the condition we use for forcing HCR_RW to be set.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3128 Fixes: 39ec3fc0301 ("target/arm: HCR_EL2.RW should be RAO/WI if EL1 doesn't support AArch32") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250925115723.1293233-1-peter.maydell@linaro.org
(cherry picked from commit a23e719ca8e80d22eafe4b2b57833918d439fa0c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This results in undefined behavior when dev->exp.sriov_cap is 0 because
this is not an SR-IOV device. For example, unparent_vfs() segfaults when
total_vfs happens to be non-zero.
Fix this by returning early from pcie_sriov_pf_exit() when
dev->exp.sriov_cap is 0 because this is not an SR-IOV device.
Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Cc: Michael S. Tsirkin <mst@redhat.com> Reported-by: Qing Wang <qinwang@redhat.com> Buglink: https://issues.redhat.com/browse/RHEL-116443 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Fixes: cab1398a60eb ("pcie_sriov: Reuse SR-IOV VF device instances") Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20250924155153.579495-1-stefanha@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit bab681f752048c3bc22d561b1d314c7ec16419c9)
(Mjt: backport to before v10.0.0-819-g19e55471d4e8
"pcie_sriov: Allow user to create SR-IOV device") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The documentation for UEFI variable storage in uefi-vars.rst
incorrectly listed the device name as `uefi-vars-x86`.
The correct device name as implemented in the source code is
`uefi-vars-x64`.
This commit updates the documentation to use the correct name,
aligning it with the implementation.
Signed-off-by: Nana Liu <nanliu@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit f65918497cc6b9034ce8f81a4df1d6407e110367) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The return value of hid_keyboard_write is used to set the packet's actual_length
and pass to xhci directly to allow guest know how many byte actually processed.
Therefore, return 1 to indicate a successful transfer or it will be
considered as a wrong xfer.
Signed-off-by: ShengYi Hung <aokblast@FreeBSD.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 1c0f5142d921525f1023152eac63d2ff3d33e3b2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Filip Hejsek [Fri, 12 Sep 2025 22:58:35 +0000 (00:58 +0200)]
ui/gtk: Fix callback function signature
The correct type for opaque pointer is gpointer,
not gpointer * (which is a pointer to a pointer).
Signed-off-by: Filip Hejsek <filip.hejsek@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit c187a67c9dcdece58138f4df5ca4dd846934eddc) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Weifeng Liu [Sun, 11 May 2025 07:33:17 +0000 (15:33 +0800)]
ui/gtk: Consider scaling when propagating ui info
The ui width and height sent to guest is supposed to be in buffer
coordinate. Hence conversion is required.
If scaling (global window scale and zooming scale) is not respected in
non-free-scale mode, window size could keep changing because of the
existence of the iteration of the following steps:
1. In resize event or configure event, a size larger (or smaller) than
the currently used one might be calculated due to not considering
scaling.
2. On reception of the display size change event in guest, the guest
might decide to do a mode setting and use the larger (or smaller)
mode.
3. When the new guest scan-out command arrives, QEMU would request the
window size to change to fit the new buffer size. This will trigger a
resize event or a configure event, making us go back to step 1.
Signed-off-by: Weifeng Liu <weifeng.liu.z@gmail.com>
Message-ID: <20250511073337.876650-8-weifeng.liu.z@gmail.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit a1b28f71f7ff0fcafbe0672b788e8e57ee4fe8f6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The problem is that the change makes qemu 10.0.x non-migratable
to subsequent qemu versions, since it requires introducing a new
machine type. This change should not have been picked up for 10.0.x.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reopens: https://gitlab.com/qemu-project/qemu/-/issues/3061 (for 10.0.x) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The problem is that the change makes qemu 10.0.x non-migratable
to subsequent qemu versions, since it requires introducing a new
machine type.
This revert re-introduces the problem with windows guests (which
is already fixed in windows but not in prior versions).
Details: https://gitlab.com/qemu-project/qemu/-/issues/3001
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Reopens: https://gitlab.com/qemu-project/qemu/-/issues/3001 (for 10.0.x) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Tue, 1 Jul 2025 10:58:09 +0000 (12:58 +0200)]
tests/functional/test_aarch64_sbsaref_freebsd: Fix the URL of the ISO image
The original image has been removed from the server, so the test
currently fails if it has to fetch the asset, but we can still
download the ISO from the archive server. While we're at it, prefer
the XZ compressed image, it's much smaller and thus the download
should be faster.
Message-ID: <20250701105809.366180-1-thuth@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 01e2b1bc27bae874bfeb6978ce093deac5bb9639) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Mon, 7 Jul 2025 18:47:36 +0000 (20:47 +0200)]
tests/functional/test_ppc_bamboo: Replace broken link with working assets
The old image that we used for testing the bamboo machine has disappeared
from the internet. Fortunately there is another kernel + initrd provided
by Cédric that can be used for testing this machine, too.
Reported-by: Stefan Hajnoczi <stefanha@gmail.com> Suggested-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250707184736.88660-1-thuth@redhat.com>
(cherry picked from commit 3b1cf40dd665a0c4c38bc339fea6eacf1742b46c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Mon, 29 Sep 2025 14:42:28 +0000 (15:42 +0100)]
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
Peter Xu [Mon, 29 Sep 2025 14:42:27 +0000 (15:42 +0100)]
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.)
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.
Juraj Marcin [Tue, 26 Aug 2025 11:51:40 +0000 (13:51 +0200)]
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: qemu-stable@nongnu.org Fixes: 48814111366b ("migration: Always set DEVICE state") Signed-off-by: Juraj Marcin <jmarcin@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20250826115145.871272-1-jmarcin@redhat.com Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 725a9e5f7885a3c0d0cd82022d6eb5a758ac9d47) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 23 Sep 2025 09:07:29 +0000 (17:07 +0800)]
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.
Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250923090729.1887406-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit be50ff3a73859ebbbdc0e6f704793062b1743d93)
(Mjt: compensate #include for the lack of v10.0.0-214-g42fa9665e5 "exec: Restrict 'cpu_ldst.h' to accel/tcg/") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Max Chou [Tue, 23 Sep 2025 09:07:28 +0000 (17:07 +0800)]
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 <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250923090729.1887406-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(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 <mjt@tls.msk.ru>
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 <valentin.haudiquet@canonical.com> Cc: qemu-stable@nongnu.org Reviewed-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250929115543.1648157-1-valentin.haudiquet@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit b25133d38fe693589cf695b85968caa0724bfafd) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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: qemu-stable@nongnu.org Cc: Sebastien Boeuf <seb@rivosinc.com> Cc: Tomasz Jeznach <tjeznach@rivosinc.com> Reviewed-by: Weiwei Li <liwei1518@gmail.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org> Tested-by: Chen Pei <cp0613@linux.alibaba.com> Tested-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
Message-ID: <20250913041233.972870-1-guoren@kernel.org>
[ Changes by AF:
- Add braces to if statements
] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 15abfced803929f935bb59a0e1b02558bd8325c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Vladimir Isaev [Fri, 15 Aug 2025 14:06:33 +0000 (17:06 +0300)]
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 <vladimir.isaev@syntacore.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250815140633.86920-1-vladimir.isaev@syntacore.com>
[ Changes by AF:
- Fixup header includes after rebase
] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit a86d3352ab70f33f5feabbf9bad9450d3c19d0bf) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
stove [Wed, 27 Aug 2025 20:36:17 +0000 (13:36 -0700)]
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 <stove@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20250827203617.79947-1-stove@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit cebaf7434b4af059caca053ee1ec7ed8df91c2a7)
(Mjt: context fix for v10.0.0-1030-gf1304836ea "target/riscv: Pass ra to riscv_csrrw") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Frank Chang [Thu, 11 Sep 2025 16:06:43 +0000 (00:06 +0800)]
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.
Signed-off-by: Frank Chang <frank.chang@sifive.com> Signed-off-by: Emmanuel Blot <emmanuel.blot@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20250911160647.5710-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 191df346175283af013f414375f4be59fb850120) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Andrew Jones [Thu, 4 Sep 2025 13:27:24 +0000 (08:27 -0500)]
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 <ajones@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20250904132723.614507-2-ajones@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 4f7528295b3e6dfe1189f660fa7865ad972d82e7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Tue, 30 Sep 2025 07:14:18 +0000 (09:14 +0200)]
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 <thuth@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250930071419.117592-1-thuth@redhat.com>
(cherry picked from commit 9163424c50981dbc4ded9990228ac01a3b193656) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
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.
Peter Maydell [Mon, 15 Sep 2025 13:29:10 +0000 (14:29 +0100)]
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: qemu-stable@nongnu.org Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2548 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit d0af3cd0274e265435170a583c72b9f0a4100dff) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit e13e1195db8af18e149065a59351ea85215645bb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When we remove dest from orig's links, we lose the link
that we rely on later to reset links. This can lead to
failure to release from spinlock with self-modifying code.
Cc: qemu-stable@nongnu.org Reported-by: 李威威 <liweiwei@kubuds.cn> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Tested-by: Anton Johansson <anjo@rev.ng>
(cherry picked from commit 03fe6659803f83690b8587d01f8ee56bb4be4b90) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Thomas Huth [Thu, 18 Sep 2025 12:51:54 +0000 (14:51 +0200)]
tests: Fix "make check-functional" for targets without thorough tests
If QEMU gets configured for a single target that does not have
any thorough functional tests, "make check-functional" currently
fails with the error message "No rule to make target 'check-func'".
This happens because "check-func" only gets defined for thorough
tests (quick ones get added to "check-func-quick" instead).
The same problem can happen with the quick tests for targets that
do not have any functional test at all. To fix it, simply make sure
that the targets are always available in the Makefile.
Reported-by: Peter Maydell <peter.maydell@linaro.org> Closes: https://gitlab.com/qemu-project/qemu/-/issues/3119 Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250918125154.126072-1-thuth@redhat.com>
(cherry picked from commit 4f1ebc7712a7db61155080164f2169320d033559) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Tue, 16 Sep 2025 16:30:30 +0000 (17:30 +0100)]
.gitlab-ci.d/buildtest.yml: Unset CI_COMMIT_DESCRIPTION for htags
In commit 52a21689cd829 we added a workaround for a bug in older
versions of htags where they fail with a weird error message if the
environment is too large. However, we missed one variable which
gitlab CI can set to the body of the commit message:
CI_COMMIT_DESCRIPTION.
Add this to the variables we unset when running htags, so that
the 'pages' job doesn't fail if the most recent commit happens
to have a very large commit message.
Cc: qemu-stable@nongnu.org Fixes: 52a21689cd8 (".gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250916163030.1467893-1-peter.maydell@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit fd34f56fe886250bdd64f9c222c1cb4c07a594ad) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 18 Sep 2025 11:42:59 +0000 (12:42 +0100)]
hw/pci-host/astro: Don't call pci_regsiter_root_bus() in init
In the astro PCI host bridge device, we call pci_register_root_bus()
in the device's instance_init. This is a problem for two reasons
* the PCI bridge is then available to the rest of the simulation
(e.g. via pci_qdev_find_device()), even though it hasn't
yet been realized
* we do not attempt to unregister in an instance_deinit,
which means that if you go through an instance_init -> deinit
lifecycle the freed memory for the host-bridge device is
left on the pci_host_bridges list
ASAN reports the resulting use-after-free:
==1776584==ERROR: AddressSanitizer: heap-use-after-free on address 0x51f00000cb00 at pc 0x5b2d460a89b5 bp 0x7ffef7617f50 sp 0x7ffef7617f48
WRITE of size 8 at 0x51f00000cb00 thread T0
#0 0x5b2d460a89b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5
#1 0x5b2d46093566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5
#2 0x5b2d460935e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5
#3 0x5b2d46093fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11
#4 0x5b2d46fe2335 in elroy_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/astro.c:455:16
0x51f00000cb00 is located 1664 bytes inside of 3456-byte region [0x51f00000c480,0x51f00000d200)
freed by thread T0 here:
#0 0x5b2d4582385a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8)
#1 0x5b2d47160723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9
#2 0x5b2d471589db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9
#3 0x5b2d477d373c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5
previously allocated by thread T0 here:
#0 0x5b2d45823af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8)
#1 0x79728fa08b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5b2d471595fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15
#3 0x5b2d47159409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12
#4 0x5b2d477d29a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11
Cc: qemu-stable@nongnu.org Fixes: e029bb00a79be ("hw/pci-host: Add Astro system bus adapter found on PA-RISC machines")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250918114259.1802337-3-peter.maydell@linaro.org>
(cherry picked from commit 76d2b8d42adb0db2d1ccd08a626f25ddd30208a8) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 18 Sep 2025 11:42:58 +0000 (12:42 +0100)]
hw/pci-host/dino: Don't call pci_register_root_bus() in init
In the dino PCI host bridge device, we call pci_register_root_bus()
in the device's instance_init. This is a problem for two reasons
* the PCI bridge is then available to the rest of the simulation
(e.g. via pci_qdev_find_device()), even though it hasn't
yet been realized
* we do not attempt to unregister in an instance_deinit,
which means that if you go through an instance_init -> deinit
lifecycle the freed memory for the host-bridge device is
left on the pci_host_bridges list
ASAN reports the resulting use-after-free:
==1771223==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000018f80 at pc 0x5b4b9d3369b5 bp 0x7ffd01929980 sp 0x7ffd01929978
WRITE of size 8 at 0x527000018f80 thread T0
#0 0x5b4b9d3369b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5
#1 0x5b4b9d321566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5
#2 0x5b4b9d3215e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5
#3 0x5b4b9d321fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11
#4 0x5b4b9d390521 in dino_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/dino.c:473:16
0x527000018f80 is located 1664 bytes inside of 12384-byte region [0x527000018900,0x52700001b960)
freed by thread T0 here:
#0 0x5b4b9cab185a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140)
#1 0x5b4b9e3ee723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9
#2 0x5b4b9e3e69db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9
#3 0x5b4b9ea6173c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5
#4 0x5b4b9ec4e0f3 in qmp_marshal_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qapi/qapi-commands-qdev.c:65:14
previously allocated by thread T0 here:
#0 0x5b4b9cab1af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140)
#1 0x799d8270eb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x5b4b9e3e75fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15
#3 0x5b4b9e3e7409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12
#4 0x5b4b9ea609a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11
where we allocated one instance of the dino device, put it on the
list, freed it, and then trying to allocate a second instance touches
the freed memory on the pci_host_bridges list.
Fix this by deferring all the setup of memory regions and registering
the PCI bridge to the device's realize method. This brings it into
line with almost all other PCI host bridges, which call
pci_register_root_bus() in realize.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Fixes: 63901b6cc4d8b4 ("dino: move PCI bus initialisation to dino_pcihost_init()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250918114259.1802337-2-peter.maydell@linaro.org>
(cherry picked from commit e4a1b308b27cd77338b8f05d3a31e6b38eb717c7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [12:5] are ignored for !imm.
For v8, those same bits are reserved, but are not trapped.
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit df663ac0a4e5d916b6b3e77552a925fec02bced4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: e8325dc02d0 ("target/sparc: Move RDTBR, FLUSHW to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 6ff52f9dee064d3c2138426834320f5877863d9b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: 5d617bfba07 ("target/sparc: Move RDWIM, RDPR to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit dc9678cc9725d6c3053c6f110f162d956eb9d48f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
For v7, bits [18:0] are ignored.
For v8, bits [18:14] are reserved and bits [13:0] are ignored.
Fixes: 668bb9b755e ("target/sparc: Move RDPSR, RDHPR to decodetree") Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a0345f628394fbd001276c80fd02c8ad0d1b7ee2) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Bits [18:0] are not decoded with v7, and for v8 unused values
of rs1 simply produce undefined results.
Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
(cherry picked from commit 49d669ccf33a772e3baf3fe4ebb996dc015f46c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Solaris 8 appears to have a bug whereby it executes v9 MEMBAR
instructions when booting a freshly installed image. According
to the SPARC v8 architecture manual, whilst bits 13 and bits 12-0
of the "Read State Register Instructions" are notionally zero,
they are marked as unused (i.e. ignored).
Fixes: af25071c1d ("target/sparc: Move RDASR, STBAR, MEMBAR to decodetree")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3097 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
(cherry picked from commit b6cdd6c6050567c02a3b3cd428f85bb79d7455aa) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
target/sparc: Allow TRANS macro with no extra arguments
Use ## to drop the preceding comma if __VA_ARGS__ is empty.
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit b7cd0a1821adf9906c5edb248394bb2a95482656) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Fri, 19 Sep 2025 08:20:54 +0000 (10:20 +0200)]
linux-user: avoid -Werror=int-in-bool-context
linux-user is failing to compile on Fedora 43:
../linux-user/strace.c:57:66: error: enum constant in boolean context [-Werror=int-in-bool-context]
57 | #define FLAG_BASIC(V, M, N) { V, M | QEMU_BUILD_BUG_ON_ZERO(!(M)), N }
The warning does not seem to be too useful and we could even disable it,
but the workaround is simple in this case.
Cc: qemu-stable@nongnu.org Cc: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit db05b0d21ec1e0532cf5f5103ae6520a838d96f9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
We can see that the instruction at 0x1e3 is a far jmp through the GDT.
However, the GDT is not 8 byte aligned, the base is 0xc02b4.
Intel processors follow the LOCK semantics to set the accessed flag of the
segment descriptor when loading a segment descriptor. If the the segment
descriptor crosses two cache line, it causes split lock.
Fix it by aligning the GDT on 8 bytes, so that segment descriptor cannot
span two cache lines.
Xiaoyao Li [Wed, 30 Jul 2025 09:52:53 +0000 (17:52 +0800)]
target/i386: Define enum X86ASIdx for x86's address spaces
Define X86ASIdx as enum, like ARM's ARMASIdx, so that it's clear index 0
is for memory and index 1 is for SMM.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-By: Kirill Martynov <stdcalllevi@yandex-team.ru> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250730095253.1833411-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 591f817d819f5511fd9001dc863a326d23088811)
(Mjt: pick this change for completness with the previous one) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Xiaoyao Li [Wed, 30 Jul 2025 09:52:52 +0000 (17:52 +0800)]
i386/cpu: Enable SMM cpu address space under KVM
Kirill Martynov reported assertation in cpu_asidx_from_attrs() being hit
when x86_cpu_dump_state() is called to dump the CPU state[*]. It happens
when the CPU is in SMM and KVM emulation failure due to misbehaving
guest.
The root cause is that QEMU i386 never enables the SMM address space for
cpu since KVM SMM support has been added.
Enable the SMM cpu address space under KVM when the SMM is enabled for
the x86machine.
hw/usb/network: Remove hardcoded 0x40 prefix in STRING_ETHADDR response
USB NICs have a "40:" prefix hardcoded for all MAC addresses when we
return the guest the MAC address if it queries the STRING_ETHADDR USB
string property. This doesn't match what we use for the
OID_802_3_PERMANENT_ADDRESS or OID_802_3_CURRENT_ADDRESS OIDs for
NDIS, or the MAC address we actually use in the QEMU networking code
to send/receive packets for this device, or the NIC info string we
print for users. In all those other places we directly use
s->conf.macaddr.a, which is the full thing the user asks for.
This overrides user-provided configuration and leads to an inconsistent
experience.
I couldn't find any documented reason (comment or git commits) for
this behavior. It seems like everyone is just expecting the MAC
address to be fully passed through to the guest, but it isn't.
This may have been a debugging hack that accidentally made it through
to the accepted patch: it has been in the code since it was originally
added back in 2008.
This is also particularly problematic as the "40:" prefix isn't a
reserved prefix for MAC addresses (IEEE OUI). There are a number of
valid allocations out there which use this prefix, meaning that QEMU
may be causing MAC address conflicts.
Cc: qemu-stable@nongnu.org Fixes: 6c9f886ceae5b ("Add CDC-Ethernet usb NIC (original patch from Thomas Sailer)" Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2951 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
[PMM: beef up commit message based on mailing list discussion] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit aaf042299acf83919862c7d7dd5fc36acf4e0671) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 16 Jun 2025 16:56:49 +0000 (18:56 +0200)]
rust: hpet: fix new warning
Nightly rustc complains that HPETAddrDecode has a lifetime but it is not
clearly noted that it comes from &self. Apply the compiler's suggestion
to shut it up.
Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6b3fad084fc4e13901e252fe6c2a2c46ecea999b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Paolo Bonzini [Mon, 5 May 2025 14:23:26 +0000 (16:23 +0200)]
ci: run RISC-V cross jobs by default
The riscv64-debian-cross container is based on Trixie rather than sid
these days, so it is pretty much as stable as the others. Enable it
by default.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit eb8f7292e1315be0e36000a847b77153dcf460ef) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Alex Bennée [Mon, 8 Sep 2025 14:19:11 +0000 (15:19 +0100)]
.gitmodules: move u-boot mirrors to qemu-project-mirrors
To continue our GitLab Open Source Program license we need to pass an
automated license check for all repos under qemu-project. While U-Boot
is clearly GPLv2 rather than fight with the automated validation
script just move the mirror across to a separate project.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Suggested-by: Daniel P. Berrangé <berrange@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250908141911.2546063-1-alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a11d1847d5ef8a7db58e6d4e44f36fec708f0981) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Of most importance is that this gives us a heads-up if anything
we rely on has been deprecated. The default python behaviour
only emits a warning if triggered from __main__ which is very
limited.
Setting the env variable further ensures that any python child
processes will also display warnings.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 9a494d83538680651197651031375c2b6fa2490b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The iotest 151 creates a bunch of subprocesses, with their stdout
connected to a pipe but never reads any data from them and does
not gurantee the processes are killed on cleanup.
This triggers resource leak warnings from python when the
subprocess.Popen object is garbage collected.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 2b2fb25c2aaf5b2e8172d845db39cc50a951a12e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
iotests/147: ensure temporary sockets are closed before exiting
This avoids the python resource leak detector from issuing warnings
in the iotests.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit d4d0ebfcc926c11d16320d0d5accf22e3441c115) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
python: ensure QEMUQtestProtocol closes its socket
While QEMUQtestMachine closes the socket that was passed to
QEMUQtestProtocol, the python resource leak manager still
believes that the copy QEMUQtestProtocol holds is open. We
must explicitly call close to avoid this leak warnnig.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 6ccb48ffc19fe25511313a246d4a8bad51114ea9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
iotests: drop compat for old version context manager
Our minimum python is now 3.9, so back compat with prior
python versions is no longer required.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 82c7cb93c750196f513a1b11cb85e0328bad444f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Wed, 3 Sep 2025 05:06:30 +0000 (01:06 -0400)]
python: backport 'avoid creating additional event loops per thread'
This commit is two backports squashed into one to avoid regressions.
python: *really* remove get_event_loop
A prior commit, aa1ff990, switched away from using get_event_loop *by
default*, but this is not good enough to avoid deprecation warnings as
`asyncio.get_event_loop_policy().get_event_loop()` is *also*
deprecated. Replace this mechanism with explicit calls to
asyncio.get_new_loop() and revise the cleanup mechanisms in __del__ to
match.
python: avoid creating additional event loops per thread
"Too hasty by far!", commit 21ce2ee4 attempted to avoid deprecated
behavior altogether by calling new_event_loop() directly if there was no
loop currently running, but this has the unfortunate side effect of
potentially creating multiple event loops per thread if tests
instantiate multiple QMP connections in a single thread. This behavior
is apparently not well-defined and causes problems in some, but not all,
combinations of Python interpreter version and platform environment.
Partially revert to Daniel Berrange's original patch, which calls
get_event_loop and simply suppresses the deprecation warning in
Python<=3.13. This time, however, additionally register new loops
created with new_event_loop() so that future calls to get_event_loop()
will return the loop already created.
Reported-by: Richard W.M. Jones <rjones@redhat.com> Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@21ce2ee4f2df87efe84a27b9c5112487f4670622
cherry picked from commit python-qemu-qmp@c08fb82b38212956ccffc03fc6d015c3979f42fe Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 85f223e5b031eb8ab63fbca314a4fb296a3a2632) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This method was deprecated in 3.12 because it ordinarily should not be
used from coroutines; if there is not a currently running event loop,
this automatically creates a new event loop - which is usually not what
you want from code that would ever run in the bottom half.
In our case, we do want this behavior in two places:
(1) The synchronous shim, for convenience: this allows fully sync
programs to use QEMUMonitorProtocol() without needing to set up an event
loop beforehand. This is intentional to fully box in the async
complexities into the legacy sync shim.
(2) The qmp_tui shell; instead of relying on asyncio.run to create and
run an asyncio program, we need to be able to pass the current asyncio
loop to urwid setup functions. For convenience, again, we create one if
one is not present to simplify the creation of the TUI appliance.
The remaining user of get_event_loop() was in fact one of the erroneous
users that should not have been using this function: if there's no
running event loop inside of a coroutine, you're in big trouble :)
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@aa1ff9907603a3033296027e1bd021133df86ef1 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 5d99044d09db0fa8c2b3294e301927118f9effc9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Fri, 22 Jul 2022 19:55:45 +0000 (15:55 -0400)]
python: backport 'qmp-tui: Do not crash if optional dependencies are not met'
Based on the discussion at https://github.com/pypa/pip/issues/9726 -
even though the setuptools documentation implies that it is possible to
guard script execution with optional dependency groups, this is not true
in practice with the scripts generated by pip.
Just do the simple thing and guard the import statements.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@df520dcacf9a75dd4c82ab1129768de4128b554c Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit fd0ed46d4effbf2700804657bad9c6db086527c4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@9c889dcbd58817b0c917a9d2dd16161f48ac8203 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit fcaeeb7653d2c6f38183170e1cae5729adb7875c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 6 Jun 2023 17:45:44 +0000 (13:45 -0400)]
python: backport 'Use @asynciocontextmanager'
This removes a non-idiomatic use of a "coroutine callback" in favor of
something a bit more standardized.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@commit 97f7ffa3be17a50544b52767d14b6fd478c07b9e Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 0408b8d7a086486f5c1887798be744b2d73bcda9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 6 Jun 2023 17:19:11 +0000 (13:19 -0400)]
python: backport 'drop Python3.6 workarounds'
Now that the minimum version is 3.7, drop some of the 3.6-specific hacks
we've been carrying. A single remaining compatibility hack concerning
3.6's lack of @asynccontextmanager is addressed in the following commit.
Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@3e8e34e594cfc6b707e6f67959166acde4b421b8 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit f9d2e0a3bd7ba2a693a892881f91cf53fa90cc71) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
John Snow [Tue, 3 May 2022 18:07:10 +0000 (14:07 -0400)]
python: backport 'kick event queue on legacy event_pull()'
This corrects an oversight in qmp-shell operation where new events will
not accumulate in the event queue when pressing "enter" with an empty
command buffer, so no new events show up.
Reported-by: Jag Raman <jag.raman@oracle.com> Signed-off-by: John Snow <jsnow@redhat.com>
cherry picked from commit python-qemu-qmp@0443582d16cf9efd52b2c41a7b5be7af42c856cd Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 1e343714bfc06cc982e68a290f3809117d6dfcd0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
The required "id" is only set up automatically while parsing the command
line, but not when reading the options from the config file.
Thus let's move code that automatically adds the id (if it does not
exist yet) to the init function that needs the id for the first time,
replacing the assert() statement there.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2836 Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20250821145130.845104-1-thuth@redhat.com>
(cherry picked from commit 38dd513263d814dc3cf554b899c118a46ca77577) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
WANG Rui [Fri, 25 Jul 2025 03:12:32 +0000 (11:12 +0800)]
target/loongarch: Guard 64-bit-only insn translation with TRANS64 macro
This patch replaces uses of the generic TRANS macro with TRANS64 for
instructions that are only valid when 64-bit support is available.
This improves correctness and avoids potential assertion failures or
undefined behavior during translation on 32-bit-only configurations.
Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 96e7448c1f820c56caea8447c01f5227b0c95c79) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
WANG Rui [Fri, 18 Apr 2025 08:21:01 +0000 (16:21 +0800)]
target/loongarch: Add CRC feature flag and use it to gate CRC instructions
This patch replaces the obsolete IOCSR_BRD bit with CRC in cpucfg1[25],
in both LA464 and LA132 CPU initialization functions. The corresponding
field macro in `cpu.h` is updated to reflect this change.
Additionally, the availability macro `avail_CRC()` is introduced in
`translate.h` to check the CRC feature flag.
All CRC-related instruction translations are updated to be gated by
the new CRC feature flag instead of hardcoded CPU features.
This ensures correctness and configurability when enabling CRC
instructions based on hardware capabilities.
Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20250418082103.447780-2-wangrui@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 256df51e727235b3d5e937ca2784c45663c00f59)
(Mjt: pick this one up for 10.0.x so subsequent changes applies cleanly) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Tokarev [Sun, 24 Aug 2025 00:05:32 +0000 (03:05 +0300)]
block/curl: fix curl internal handles handling
block/curl.c uses CURLMOPT_SOCKETFUNCTION to register a socket callback.
According to the documentation, this callback is called not just with
application-created sockets but also with internal curl sockets, - and
for such sockets, user data pointer is not set by the application, so
the result qemu crashing.
Pass BDRVCURLState directly to the callback function as user pointer,
instead of relying on CURLINFO_PRIVATE.
This problem started happening with update of libcurl from 8.9 to 8.10 --
apparently with this change curl started using private handles more.
(CURLINFO_PRIVATE is used in one more place, in curl_multi_check_completion() -
it might need a similar fix too)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3081 Cc: qemu-stable@qemu.org Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 606978500c3d18fb89a49844f253097b17f757de) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 21 Aug 2025 15:44:59 +0000 (16:44 +0100)]
hw/gpio/pca9554: Avoid leak in pca9554_set_pin()
In pca9554_set_pin() we have a string property which we parse in
order to set some non-string fields in the device state. So we call
visit_type_str(), passing it the address of the local variable
state_str.
visit_type_str() will allocate a new copy of the string; we
never free this string, so the result is a memory leak, detected
by ASAN during a "make check" run:
Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (
BuildId: 3d5373c89317f58bfcd191a33988c7347714be14)
#1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo
bject-input-visitor.c:542:12
#5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit
-core.c:349:10
#6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10
#7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5
#8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10
#9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15
#10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5
#11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9
Make the state_str g_autofree, so that we will always free
it, on both error-exit and success codepaths.
Cc: qemu-stable@nongnu.org Fixes: de0c7d543bca ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3284d1c07cfd8d42aa27d1cf83d3e65fcd62e35e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Aditya Gupta [Wed, 20 Aug 2025 12:25:17 +0000 (17:55 +0530)]
hw/ppc: Fix build error with CONFIG_POWERNV disabled
Currently when CONFIG_POWERNV is not enabled, the build fails, such as
with --without-default-devices:
$ ./configure --without-default-devices
$ make
[281/283] Linking target qemu-system-ppc64
FAILED: qemu-system-ppc64
cc -m64 @qemu-system-ppc64.rsp
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_load_sprd':
.../target/ppc/misc_helper.c:335:(.text+0xcdc): undefined reference to `pnv_chip_find_core'
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_store_sprd':
.../target/ppc/misc_helper.c:375:(.text+0xdf4): undefined reference to `pnv_chip_find_core'
collect2: error: ld returned 1 exit status
...
This is since target/ppc/misc_helper.c references PowerNV specific
'pnv_chip_find_core' call.
Split the PowerNV specific SPRD code out of the generic PowerPC code, by
moving the SPRD code to pnv.c
Fixes: 9808ce6d5cb ("target/ppc: Big-core scratch register fix") Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Acked-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20250820122516.949766-2-adityag@linux.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 46d03bb23dde86513465724760d85f42eb17539e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis Rastyogin [Thu, 14 Aug 2025 10:48:32 +0000 (13:48 +0300)]
target/mips: fix TLB huge page check to use 64-bit shift
Use extract64(entry, psn, 1) instead of (entry & (1 << psn)) to avoid
undefined behavior for shifts by 32–63 and to make bit extraction intent explicit.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Rastyogin <gerben@altlinux.org>
Message-ID: <20250814104914.13101-1-gerben@altlinux.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1f82ca723478f44823a18e7151e487d58da03659) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select M14Kc CPU to run microMIPS binaries
The M14Kc is our latest CPU supporting the microMIPS ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting microMIPS ASE.
Cc: qemu-stable@nongnu.org Fixes: 3c824109da0 ("target-mips: microMIPS ASE support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-4-philmd@linaro.org>
(cherry picked from commit 51c3aebfda6489b49cebef593a1ceb597cb97a7e)
(Mjt: in 10.1 and before, the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select 74Kf CPU to run MIPS16e binaries
The 74Kf is our latest CPU supporting MIPS16e ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting MIPS16e ASE.
Cc: qemu-stable@nongnu.org Fixes: 6ea219d0196..d19954f46df ("target-mips: MIPS16 support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-3-philmd@linaro.org>
(cherry picked from commit 7a09b3cc70ab6d717b18dec5c5995f7a06af4593)
(Mjt: in 10.1 and before the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Include MIPS ASE ELF definitions from binutils:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/mips.h;h=4fc190f404d828ded84e621bfcece5fa9f9c23c8;hb=HEAD#l210
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-2-philmd@linaro.org>
(cherry picked from commit 14ab44b96d5bf761af81cc723314ef5ecf73ed17) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Laurent Vivier [Thu, 7 Aug 2025 11:08:06 +0000 (13:08 +0200)]
e1000e: Prevent crash from legacy interrupt firing after MSI-X enable
A race condition between guest driver actions and QEMU timers can lead
to an assertion failure when the guest switches the e1000e from legacy
interrupt mode to MSI-X. If a legacy interrupt delay timer (TIDV or
RDTR) is active, but the guest enables MSI-X before the timer fires,
the pending interrupt cause can trigger an assert in
e1000e_intmgr_collect_delayed_causes().
This patch removes the assertion and executes the code that clears the
pending legacy causes. This change is safe and introduces no unintended
behavioral side effects, as it only alters a state that previously led
to termination.
- when core->delayed_causes == 0 the function was already a no-op and
remains so.
- when core->delayed_causes != 0 the function would previously
crash due to the assertion failure. The patch now defines a safe
outcome by clearing the cause and returning. Since behavior after
the assertion never existed, this simply corrects the crash.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1863 Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250807110806.409065-1-lvivier@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 8e4649cac9bcddc050d2df07908075e9e69bccc7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
vfio scsi ui: Error-check qio_channel_socket_connect_sync() the same way
qio_channel_socket_connect_sync() returns 0 on success, and -1 on
failure, with errp set. Some callers check the return value, and some
check whether errp was set.
For consistency, always check the return value, and always check it's
negative.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-3-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit ec14a3de622ae30a8afa78b6f564bc743b753ee1)
(Mjt: drop changes for hw/vfio-user/proxy.c which is not in 10.0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
i386/kvm/vmsr_energy: Plug memory leak on failure to connect socket
vmsr_open_socket() leaks the Error set by
qio_channel_socket_connect_sync(). Plug the leak by not creating the
Error.
Fixes: 0418f90809ae (Add support for RAPL MSRs in KVM/Qemu) Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-2-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit b2e4534a2c9ce3d20ba44d855f1e2b71cc53c3a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
QGA-VSS writes error using error_setg_win32_internal,
which call g_win32_error_message.
g_win32_error_message - translate a Win32 error code
(as returned by GetLastError()) into the corresponding message.
In the same time, we call error_setg_win32_internal with
error codes from different Windows componets like VSS or
Performance monitor that provides different codes and
can't be converted with g_win32_error_message. In this
case, the empty suffix will be returned so error will be
masked.
This commit directly add hex value of error code.
Reproduce:
- Run QGA command: {"execute": "guest-fsfreeze-freeze-list", "arguments": {"mountpoints": ["D:"]}}
QGA error example:
- before changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: "}}
- after changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: Windows error 0x8004230e: "}}
qga/installer: Remove QGA VSS if QGA installation failed
When QGA Installer failed to install QGA service but install
QGA VSS provider, provider should be removed before installer
exits. Otherwise QGA VSS will has broken infomation and
prevent QGA installation in next run.
In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we call object_new() and then later qdev_realize(),
and we never unref the object on deinit. This causes a leak,
detected by ASAN on the device-introspect-test:
Indirect leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe)
#1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18
#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12
#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10
#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12
#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9
#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5
#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5
#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9
#12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5
#13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5
#14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26
Switch to using object_initialize_child() like all our
other child objects for this SoC object.
Cc: qemu-stable@nongnu.org Fixes: b63041c8f6b ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org
(cherry picked from commit 2e27650bddd35477d994a795a3b1cb57c8ed5c76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
projects / thirdparty / qemu.git / log
