Branch: refs/heads/staging-10.2
Home: https://github.com/qemu/qemu
Commit: 2cfc92842a7f61e98836451def15f0d7aa6f0b38
https://github.com/qemu/qemu/commit/2cfc92842a7f61e98836451def15f0d7aa6f0b38
Author: Jaehoon Kim <[email protected]>
Date: 2026-02-12 (Thu, 12 Feb 2026)
Changed paths:
M hw/s390x/s390-pci-inst.c
Log Message:
-----------
s390x/pci: Fix endianness for zPCI BAR values.
During zPCI scan, BAR configuration data retrieved via CLP Query was
misinterpreted due to an endianness mismatch between QEMU and the guest
kernel.
The guest kernel's clp_store_query_pci_fn() expects BAR values in
little-endian format and converts them with le32_to_cpu(). However, QEMU
was incorrectly sending them in big-endian format, not following the
architecture specification. This caused incorrect bit-swapping in the
kernel, leading zpci_setup_bus_resources() to perform registration checks
against invalid flags, making the process ineffective.
Observation values for zPCI device (NVMe passthrough):
LPAR from real CLP:
[ 0.865595] Resource: PCI Bus 0000:00 -> zdev->bar[0].val: 0x4
[ 0.865597] start: 0x4000000000000000
[ 0.865598] end: 0x4000000000003fff
[ 0.865600] flags: 0x100200
QEMU before fix (wrong):
[ 0.601083] Resource: PCI Bus 0001:00 -> zdev->bar[0].val: 0x4000000
[ 0.601085] start: 0x4003000000000000
[ 0.601086] end: 0x4003000000003fff
[ 0.601087] flags: 0x200
QEMU after fix (correct):
[ 0.601116] Resource: PCI Bus 0001:00 -> zdev->bar[0].val: 0x4
[ 0.601117] start: 0x4003000000000000
[ 0.601118] end: 0x4003000000003fff
[ 0.601119] flags: 0x100200
Signed-off-by: Jaehoon Kim <[email protected]>
Reviewed-by: Matthew Rosato <[email protected]>
Reviewed-by: Farhan Ali <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 00ebc44514a67fb75a46d60e4b44614ebf91230f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 24690bf83669946949eea6090ea91e54ccdeaa2a
https://github.com/qemu/qemu/commit/24690bf83669946949eea6090ea91e54ccdeaa2a
Author: Mohamed Mediouni <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M plugins/meson.build
Log Message:
-----------
plugins: fix cross-build using LLVM for Windows targets
llvm-dlltool assumes that it's by default targeting the host architecture
it's running on. That assumption doesn't hold true when cross-compiling.
Signed-off-by: Mohamed Mediouni <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Tested-by: Pierrick Bouvier <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Pierrick Bouvier <[email protected]>
(cherry picked from commit b0353beebb0c4fa4059c88362561a8362ada8b4c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8d2f7ef7c00f7e8e72bb757444d37bb8a2d1766c
https://github.com/qemu/qemu/commit/8d2f7ef7c00f7e8e72bb757444d37bb8a2d1766c
Author: Fiona Ebner <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M block/mirror.c
Log Message:
-----------
block/mirror: check range when setting zero bitmap for sync write
Some Proxmox users reported an occasional assertion failure [0][1] in
busy VMs when using drive mirror with active mode. In particular, the
failure may occur for zero writes shorter than the job granularity:
> #0 0x00007b421154b507 in abort ()
> #1 0x00007b421154b420 in ?? ()
> #2 0x0000641c582e061f in bitmap_set (map=0x7b4204014e00, start=14, nr=-1)
> #3 0x0000641c58062824 in do_sync_target_write (job=0x641c7e73d1e0,
> method=MIRROR_METHOD_ZERO, offset=852480, bytes=4096, qiov=0x0, flags=0)
> #4 0x0000641c58062250 in bdrv_mirror_top_do_write (bs=0x641c7e62e1f0,
method=MIRROR_METHOD_ZERO, copy_to_target=true, offset=852480,
bytes=4096, qiov=0x0, flags=0)
> #5 0x0000641c58061f31 in bdrv_mirror_top_pwrite_zeroes (bs=0x641c7e62e1f0,
offset=852480, bytes=4096, flags=0)
The range for the dirty bitmap described by dirty_bitmap_offset and
dirty_bitmap_end is narrower than the original range and in fact,
dirty_bitmap_end might be smaller than dirty_bitmap_offset. There
already is a check for 'dirty_bitmap_offset < dirty_bitmap_end' before
resetting the dirty bitmap. Add such a check for setting the zero
bitmap too, which uses the same narrower range.
[0]: https://forum.proxmox.com/threads/177981/
[1]: https://bugzilla.proxmox.com/show_bug.cgi?id=7222
Cc: [email protected]
Fixes: 7e277545b9 ("mirror: Skip writing zeroes when target is already zero")
Signed-off-by: Fiona Ebner <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 4a7b1bd18d2e1a6b3796e177ae5df9b198264a0b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 641cb36c075ab7fa0c911acf47dffa6554414e34
https://github.com/qemu/qemu/commit/641cb36c075ab7fa0c911acf47dffa6554414e34
Author: Fiona Ebner <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M tests/qemu-iotests/151
M tests/qemu-iotests/151.out
Log Message:
-----------
iotests: test active mirror with unaligned, small write zeroes op
This tests the scenario fixed by "block/mirror: check range
when setting zero bitmap for sync write" [0].
[0]
https://lore.kernel.org/qemu-devel/[email protected]/
Signed-off-by: Fiona Ebner <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Tested-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]>
(cherry picked from commit 267d7ae99a1d3b5be9d3421db3bdf651cc18c7ab)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6500ee3d5ae253438a32c16ce6a69d2f6edd0ce1
https://github.com/qemu/qemu/commit/6500ee3d5ae253438a32c16ce6a69d2f6edd0ce1
Author: John Snow <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M python/setup.py
Log Message:
-----------
python: drop uses of pkg_resources
pkg_resources has been fully dropped from modern pip/setuptools
distributions and we should phase out its use. This patch is enough to,
by itself, repair most GitLab CI tests upstream; with the exception of
tox tests which are still making use of avocado - which will be dropped
in a separate series to restore functionality there.
Signed-off-by: John Snow <[email protected]>
Suggested-by: Peter Maydell <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e44a26ba940214824b61976324058e73d9f41658)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2729113a79d70aba6d73c43a9437a199bd778ae5
https://github.com/qemu/qemu/commit/2729113a79d70aba6d73c43a9437a199bd778ae5
Author: Alex Bradbury <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M contrib/plugins/hotblocks.c
Log Message:
-----------
contrib/plugins/hotblocks: Correctly free sorted counts list
g_list_free should be passed the head of the list.
Signed-off-by: Alex Bradbury <[email protected]>
Reviewed-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/cf5a00136738b981a12270b76572e8d502daf208.1753857212.git....@igalia.com
Signed-off-by: Pierrick Bouvier <[email protected]>
(cherry picked from commit 90fabd5ddace6ffa5a62a5186201fd071b4e2b74)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 85327403337a2a93334fc2361a8cbc6c2bc6a03f
https://github.com/qemu/qemu/commit/85327403337a2a93334fc2361a8cbc6c2bc6a03f
Author: Alex Bradbury <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M contrib/plugins/hotblocks.c
Log Message:
-----------
contrib/plugins/hotblocks: Fix off by one error in iteration of sorted blocks
The logic to iterate over the hottest blocks will never reach the last
item in the list, as it checks `it->next != NULL` before entering the
loop. It's hard to trigger this off-by-one error with the default
limit=20, but it is a bug and is problematic if that default is changed
to something larger.
Signed-off-by: Alex Bradbury <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/f1ba2e57c6126472c0c8310774009f2455efc370.1753857212.git....@igalia.com
Signed-off-by: Pierrick Bouvier <[email protected]>
(cherry picked from commit 1c1e45fcd66269f8a6dbd97fd7b8267d8f6f58af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cb327d638f414b05651dc0e6f18e6419623efac1
https://github.com/qemu/qemu/commit/cb327d638f414b05651dc0e6f18e6419623efac1
Author: Alex Bradbury <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M contrib/plugins/hotblocks.c
Log Message:
-----------
contrib/plugins/hotblocks: Print uint64_t with PRIu64 rather than PRId64
qemu_plugin_u64_sum returns a uint64_t, so PRIu64 is the correct format
specifier.
Signed-off-by: Alex Bradbury <[email protected]>
Reviewed-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/5d26c9d99ee87ac4a4034ff64e3d8881253eedf3.1753857212.git....@igalia.com
Signed-off-by: Pierrick Bouvier <[email protected]>
(cherry picked from commit e777f6ab91406884136b5679a9d64124832668d8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 713e807357f980958013a166141ccc547487ecce
https://github.com/qemu/qemu/commit/713e807357f980958013a166141ccc547487ecce
Author: Alex Bradbury <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M docs/about/emulation.rst
Log Message:
-----------
docs/about/emulation: Add documentation for hotblocks plugin arguments
Currently just 'inline'.
Signed-off-by: Alex Bradbury <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/35128cc5a86a0c18418f9d3150fb8771c54ef7d8.1753857212.git....@igalia.com
Signed-off-by: Pierrick Bouvier <[email protected]>
(cherry picked from commit e4ed74c9aef68cb2e7c10c2b7597fee5491a506a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0e311e683f5a4592dfbb8a975a7d561f3e8b435a
https://github.com/qemu/qemu/commit/0e311e683f5a4592dfbb8a975a7d561f3e8b435a
Author: Jamin Lin <[email protected]>
Date: 2026-02-17 (Tue, 17 Feb 2026)
Changed paths:
M hw/i2c/aspeed_i2c.c
M include/hw/i2c/aspeed_i2c.h
Log Message:
-----------
hw/i2c/aspeed_i2c: Fix out-of-bounds read in I2C MMIO handlers
The ASPEED I2C controller exposes a per-bus MMIO window of 0x80 bytes on
AST2600/AST1030/AST2700, but the backing regs[] array was sized for only
28 dwords (0x70 bytes). This allows guest reads in the range [0x70..0x7f]
to index past the end of regs[].
Fix this by:
- Sizing ASPEED_I2C_NEW_NUM_REG to match the 0x80-byte window
(0x80 >> 2 = 32 dwords).
- Avoiding an unconditional pre-read from regs[] in the legacy/new read
handlers. Initialize the return value to -1 and only read regs[] for
offsets that are explicitly handled/valid, leaving invalid offsets to
return -1 with a guest error log.
Signed-off-by: Jamin Lin <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3290
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit c2c5beec42bf9872b37e78b9e259132df7435cb5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 188b8070ce675764afa8143272f3496c7c4df3b5
https://github.com/qemu/qemu/commit/188b8070ce675764afa8143272f3496c7c4df3b5
Author: Peter Maydell <[email protected]>
Date: 2026-02-19 (Thu, 19 Feb 2026)
Changed paths:
M target/arm/helper.c
M target/arm/internals.h
Log Message:
-----------
target/arm: Account for SME in aarch64_sve_narrow_vq() assertion
In aarch64_sve_narrow_vq() we assert that the new VQ is within
the maximum supported range for the CPU. We forgot to update
this to account for SME, which might have a different maximum.
Update the assert to permit any VQ which is valid for either
SVE or SME.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 42eab40a12f12f044a5ca7b7d889d9a1f0d172ee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: aa9c49d19e3a841575351e9329fb73467919f436
https://github.com/qemu/qemu/commit/aa9c49d19e3a841575351e9329fb73467919f436
Author: Peter Maydell <[email protected]>
Date: 2026-02-19 (Thu, 19 Feb 2026)
Changed paths:
M target/arm/tcg/translate-sve.c
Log Message:
-----------
target/arm: Fix feature check in DO_SVE2_RRX, DO_SVE2_RRX_TB
In the macros DO_SVE2_RRX and DO_SVE2_RRX_TB we use the
feature check aa64_sve, thus exposing this set of instructions
in SVE as well as SVE2. Use aa64_sve2 instead, so they UNDEF
on an SVE1-only CPU as they should.
Strictly, the condition here should be "SVE2 or SME"; but we
will correct that in a following commit with all the other
missing "or SME" checks.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Manos Pitsidianakis <[email protected]>
Message-id: [email protected]
(cherry picked from commit ee5bf0962ed6e0eb42d6bc9bfb3687f2408e3580)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: aeaff51f5838be2da82f70b5834b893fe0109ab5
https://github.com/qemu/qemu/commit/aeaff51f5838be2da82f70b5834b893fe0109ab5
Author: Peter Maydell <[email protected]>
Date: 2026-02-19 (Thu, 19 Feb 2026)
Changed paths:
M target/arm/tcg/translate-sve.c
Log Message:
-----------
target/arm/tcg: Allow SVE RAX1 in SME2p1 streaming mode
The SVE RAX1 instruction is permitted in SME streaming mode starting
from SME2p1. We forgot to allow this relaxation when we implemented
SME2p1.
Cc: [email protected]
Fixes: 7b1613a1020d2 ("target/arm: Enable FEAT_SME2p1 on -cpu max")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 433097a2242120918090201129e5fbb8e16b3e34)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5fc003f542122e0cf4aeb0789d3b119cb9851bfa
https://github.com/qemu/qemu/commit/5fc003f542122e0cf4aeb0789d3b119cb9851bfa
Author: Peter Maydell <[email protected]>
Date: 2026-02-19 (Thu, 19 Feb 2026)
Changed paths:
M docs/system/arm/cpu-features.rst
M target/arm/cpu64.c
Log Message:
-----------
target/arm: Don't let 'sme=on' downgrade SME
In our handling of the boolean 'sme' CPU property, we write this 0/1
value directly to ID_AA64PFR1_EL1.SME. This worked when the only
valid values in that field were 0 (for no SME) and 1 (for SME1).
However, with the addition of SME2 the SME field can now also read 2.
This means that "-cpu max,sme=on" will result in an inconsistent set
of ID registers, where ID_AA64PFR1_EL1.SME claims SME1 but
ID_AA64SMFR0_EL1.SMEver claims SME2p1. This isn't a valid thing to
report, and confuses Linux into reporting SME2 to userspace but not
actually enabling userspace access for it.
Fix this bug by having arm_cpu_sme_finalize() fix up the
ID_AA64PFR1_EL1.SME field to match ID_AA64SMFR0.SMEver. This means
the "sme" property's semantics are "off" for "no SME" and "on" for
"enable at whatever the default SME version this CPU provides is".
Update the documentation to clarify what 'sve=on' and 'sme=on' do.
(We don't have the equivalent bug for 'sve=on' because
ID_AA64PFR0_EL1.SVE only has 0 and 1 as valid values, but the
semantics of the property are the same.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Manos Pitsidianakis <[email protected]>
Message-id: [email protected]
(cherry picked from commit aeb3c147fc4a1eb9a73f9f10923fc06def088aeb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 22687ae317ec2e299918ce1a1eac5c7a2f2ecca6
https://github.com/qemu/qemu/commit/22687ae317ec2e299918ce1a1eac5c7a2f2ecca6
Author: Helge Deller <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/hppa/machine.c
Log Message:
-----------
hw/hppa: Add BMC on 64-bit machines only
Prevent adding the BMC with it's serial ports on 32-bit machines, even
if they have a PCI bus like the B160L. This fixes boot problems with
HP-UX on B160L.
Signed-off-by: Helge Deller <[email protected]>
Fixes: 557bc5260cfd ("hw/hppa: PCI devices depend on availability of PCI bus")
Cc: [email protected]
Reviewed-by: Anton Johansson <[email protected]>
(cherry picked from commit 16786eb7bf8644398707e64fff12e4c9564ec131)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f402cbe224337a015bc8567c19b854c4f020a6d6
https://github.com/qemu/qemu/commit/f402cbe224337a015bc8567c19b854c4f020a6d6
Author: Akihiko Odaki <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
virtio-gpu-virgl: Add virtio-gpu-virgl-hostmem-region type
Commit e27194e087ae ("virtio-gpu-virgl: correct parent for blob memory
region") made the name member of MemoryRegion unset, causing a NULL
pointer dereference[1]:
> Thread 2 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> (gdb) bt
> #0 0x00007ffff56565e2 in __strcmp_evex () at /lib64/libc.so.6
> #1 0x0000555555841bdb in find_fd (head=0x5555572337d0 <cpr_state>,
> name=0x0, id=0) at ../migration/cpr.c:68
> #2 cpr_delete_fd (name=name@entry=0x0, id=id@entry=0) at
> ../migration/cpr.c:77
> #3 0x000055555582290a in qemu_ram_free (block=0x7ff7e93aa7f0) at
> ../system/physmem.c:2615
> #4 0x000055555581ae02 in memory_region_finalize (obj=<optimized out>)
> at ../system/memory.c:1816
> #5 0x0000555555a70ab9 in object_deinit (obj=<optimized out>,
> type=<optimized out>) at ../qom/object.c:715
> #6 object_finalize (data=0x7ff7e936eff0) at ../qom/object.c:729
> #7 object_unref (objptr=0x7ff7e936eff0) at ../qom/object.c:1232
> #8 0x0000555555814fae in memory_region_unref (mr=<optimized out>) at
> ../system/memory.c:1848
> #9 flatview_destroy (view=0x555559ed6c40) at ../system/memory.c:301
> #10 0x0000555555bfc122 in call_rcu_thread (opaque=<optimized out>) at
> ../util/rcu.c:324
> #11 0x0000555555bf17a7 in qemu_thread_start (args=0x555557b99520) at
> ../util/qemu-thread-posix.c:393
> #12 0x00007ffff556f464 in start_thread () at /lib64/libc.so.6
> #13 0x00007ffff55f25ac in __clone3 () at /lib64/libc.so.6
The intention of the aforementioned commit is to prevent a MemoryRegion
from parenting itself while its references is counted indendependently
of the device. To achieve the same goal, add a type of QOM objects that
count references and parent MemoryRegions.
[1]
https://lore.kernel.org/qemu-devel/[email protected]/
Cc: [email protected]
Fixes: e27194e087ae ("virtio-gpu-virgl: correct parent for blob memory region")
Fixes: be88ad424c0b ("virtio-gpu-virgl: correct parent for blob memory region")
for 10.2.x
Signed-off-by: Akihiko Odaki <[email protected]>
Tested-by: Dmitry Osipenko <[email protected]>
Tested-by: Joelle van Dyne <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit b2a279094c3b86667969cc645f7fb1087e08dd19)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 421123a6914b68547229680c3bf989c10ea0f984
https://github.com/qemu/qemu/commit/421123a6914b68547229680c3bf989c10ea0f984
Author: Manos Pitsidianakis <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/audio/virtio-snd.c
Log Message:
-----------
virtio-snd: remove TODO comments
Replying with a VIRTIO_SND_S_BAD_MSG error does not warrant a device
reset. Instead, a device reset happens when the driver requests it from the
transport.
Signed-off-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 34238f078a04f24b91199249b83846ab082b4e05)
(Mjt: pick this one up so the next commit applies cleanly)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d84fbf241d0322f19adfbe466c60bed5f50de262
https://github.com/qemu/qemu/commit/d84fbf241d0322f19adfbe466c60bed5f50de262
Author: Manos Pitsidianakis <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/audio/virtio-snd.c
Log Message:
-----------
virtio-snd: handle 5.14.6.2 for PCM_INFO properly
The section 5.14.6.2 of the VIRTIO spec says:
5.14.6.2 Driver Requirements: Item Information Request
- The driver MUST NOT set start_id and count such that start_id +
count is greater than the total number of particular items that is
indicated in the device configuration space.
- The driver MUST provide a buffer of sizeof(struct virtio_snd_hdr) +
count * size bytes for the response.
While we performed some check for the second requirement, it failed to
check for integer overflow.
Add also a check for the first requirement, which should limit exposure
to any overflow, since realistically the number of streams will be low
enough in value such that overflow is improbable.
Cc: [email protected]
Reported-by: 罗铭源 <[email protected]>
Signed-off-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 61679d7dcfa2dffc8fb115aa19b09e0e7cf5ea5c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a730f98a7a199706c44dd86a39d961e80e2ad18f
https://github.com/qemu/qemu/commit/a730f98a7a199706c44dd86a39d961e80e2ad18f
Author: Manos Pitsidianakis <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/audio/virtio-snd.c
Log Message:
-----------
virtio-snd: fix max_size bounds check in input cb
In 98e77e3d we calculated the max size and checked that each buffer is smaller
than it.
We neglected to subtract the size of the virtio_snd_pcm_status header
from the max size, and max_size was thus larger than the correct value,
leading to potential OOB writes.
If the buffer cannot fit the header or can fit only the header, return
the buffer immediately.
Cc: [email protected]
Fixes: 98e77e3dd8dd6e7aa9a7dffa60f49c8c8a49d4e3 ("virtio-snd: add max size
bounds check in input cb")
Reported-by: DARKNAVY <[email protected]>
Signed-off-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit bcb53328aa70023f1405fade4e253e7f77567261)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 298986525140149bd749c236c17cfbb507c69e23
https://github.com/qemu/qemu/commit/298986525140149bd749c236c17cfbb507c69e23
Author: Manos Pitsidianakis <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/audio/virtio-snd.c
Log Message:
-----------
virtio-snd: tighten read amount in in_cb
The amount of bytes to read passed to AUD_read() should never surpass
the maximum available buffer length. Tighten the current amount by
MIN(<amount>, max_size - <existing size>).
Cc: [email protected]
Fixes: 98e77e3dd8dd6e7aa9a7dffa60f49c8c8a49d4e3 ("virtio-snd: add max size
bounds check in input cb")
Reported-by: DARKNAVY <[email protected]>
Signed-off-by: Manos Pitsidianakis <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 7994203bb1b83a6604f3ab00fe9598909bb66164)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dc9f0565a20b4366e17f661a54fbf5bd0d7f3fe1
https://github.com/qemu/qemu/commit/dc9f0565a20b4366e17f661a54fbf5bd0d7f3fe1
Author: Kuan-Wei Chiu <[email protected]>
Date: 2026-02-23 (Mon, 23 Feb 2026)
Changed paths:
M hw/misc/virt_ctrl.c
Log Message:
-----------
hw/misc/virt_ctrl: Fix incorrect trace event in read operation
The virt_ctrl_read() function currently invokes trace_virt_ctrl_write()
instead of trace_virt_ctrl_read(). This results in read operations
appearing as write operations in the trace output, which is misleading
during debugging and analysis.
Replace the incorrect trace call with the proper read-specific trace
event to accurately reflect the hardware behavior.
Fixes: 0791bc02b8fb ("m68k: add a system controller")
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 8608ed356ef90815cc5bcf04fcdbde987fd24bca)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7e64af64631f46e5492b5761ebc2fab5f4a0879c
https://github.com/qemu/qemu/commit/7e64af64631f46e5492b5761ebc2fab5f4a0879c
Author: Weixie Cui <[email protected]>
Date: 2026-02-26 (Thu, 26 Feb 2026)
Changed paths:
M hw/ssi/xilinx_spips.c
Log Message:
-----------
hw/ssi/xilinx_spips: Reset TX FIFO in reset
In xilinx_spips_reset() and xlnx_zynqmp_qspips_reset() a cut and
paste error meant we reset the RX FIFO twice and the TX FIFO not at
all. Correct this to reset both FIFOs.
Cc: [email protected]
Signed-off-by: Weixie Cui <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
[Rewrote commit message]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 669683cf1414ce442d2faea160dbc69747aef007)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b0560afef64310ee957b297fcb70c26beb2b0d5d
https://github.com/qemu/qemu/commit/b0560afef64310ee957b297fcb70c26beb2b0d5d
Author: Alex Bennée <[email protected]>
Date: 2026-02-26 (Thu, 26 Feb 2026)
Changed paths:
M target/arm/tcg/op_helper.c
Log Message:
-----------
target/arm: set the correct TI bits for WFIT traps
The WFIT trap should be reported as 0b10.
Cc: [email protected]
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Gustavo Romero <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 662fd548a027c9362df71ebfc0c9cdd7b1f349fb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cdafefe5aebc1d57144badf935f912c01f948dbd
https://github.com/qemu/qemu/commit/cdafefe5aebc1d57144badf935f912c01f948dbd
Author: Richie Buturla <[email protected]>
Date: 2026-03-01 (Sun, 01 Mar 2026)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
hw/9pfs: fix data race in v9fs_mark_fids_unreclaim()
A data race between v9fs_mark_fids_unreclaim() and v9fs_path_copy()
causes an inconsistent read of fidp->path. In v9fs_path_copy(), the
path size is set before the data pointer is allocated, creating a
window where size is non-zero but data is NULL.
v9fs_co_open2() holds a write lock during path modifications,
but v9fs_mark_fids_unreclaim() was not acquiring a read
lock, allowing it to race.
Fix by holding the path read lock during FID table iteration.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3300
Signed-off-by: Richie Buturla <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]/
Fixes: 7a46274529 ("hw/9pfs: Add file descriptor reclaim support")
Signed-off-by: Christian Schoenebeck <[email protected]>
(cherry picked from commit c96f6d2398a9dc068fa82088ea43020a52e2b26d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f577bc677f540b5d1f7e43cbeee85525ab656b27
https://github.com/qemu/qemu/commit/f577bc677f540b5d1f7e43cbeee85525ab656b27
Author: Christian Schoenebeck <[email protected]>
Date: 2026-03-01 (Sun, 01 Mar 2026)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
hw/9pfs: fix missing EOPNOTSUPP on Twstat and Trenameat for fs synth driver
Renaming files/dirs is only supported by path-based fs drivers. EOPNOTSUPP
should be returned on any renaming attempt for not path-based fs drivers.
This was already the case for 9p "Trename" request type. However for 9p
request types "Trenameat" and "Twstat" this was yet missing.
So fix this by checking in Twstat and Trenameat request handlers whether
the fs driver in use is really path based, if not return EOPNOTSUPP and
abort further handling of the request.
This fixes a crash with the 9p "synth" fs driver which is not path-based.
The crash happened because the synth driver stores and expects a raw
V9fsSynthNode pointer instead of a C-string on V9fsPath.data. So the
C-string delivered by 9p server to synth fs driver was incorrectly
casted to a V9fsSynthNode pointer, eventually causing a segfault.
Reported-by: Oliver Chang <[email protected]>
Fixes: https://issues.oss-fuzz.com/issues/477990727
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3298
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Link: https://lore.kernel.org/qemu-devel/[email protected]/
(cherry picked from commit b72d15f47cbd2fc93580f33fa86a7e23595a68dd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7426a375bcb6e68abc9a7da49f40bcf941e8c7b1
https://github.com/qemu/qemu/commit/7426a375bcb6e68abc9a7da49f40bcf941e8c7b1
Author: Josh Poimboeuf <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M hw/i386/vmmouse.c
Log Message:
-----------
hw/i386/vmmouse: Fix hypercall clobbers
Fedora QA reported the following kernel panic:
BUG: unable to handle page fault for address: 0000000040003e54
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1082ec067 P4D 0
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
6.19.0-0.rc4.260108gf0b9d8eb98df.34.fc43.x86_64 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43
11/19/2025
RIP: 0010:vmware_hypercall4.constprop.0+0x52/0x90
Code: 48 83 c4 20 5b e9 69 f0 fc fe 8b 05 a0 c1 b2 01 85 c0 74 23 b8 68 58 4d
56 b9 27 00 00 00 31 d2 bb 04 00 00 00 66 ba 58 56 ed <89> 1f 89 0e 41 89 10 5b
e9 3c f0 fc fe 6a 00 49 89 f9 45 31 c0 31
RSP: 0018:ff5eeb3240003e40 EFLAGS: 00010046
RAX: 0000000000000000 RBX: 000000000000ffca RCX: 000000000000ffac
RDX: 0000000000000000 RSI: 0000000040003e58 RDI: 0000000040003e54
RBP: ff1e05f3c1204800 R08: ff5eeb3240003e5c R09: 000000009d899c41
R10: 000000000000003d R11: ff5eeb3240003ff8 R12: 0000000000000000
R13: 00000000000000ff R14: ff1e05f3c02f9e00 R15: 000000000000000c
FS: 0000000000000000(0000) GS:ff1e05f489e40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000040003e54 CR3: 000000010841d002 CR4: 0000000000771ef0
PKRU: 55555554
Call Trace:
<IRQ>
vmmouse_report_events+0x13e/0x1b0
psmouse_handle_byte+0x15/0x60
ps2_interrupt+0x8a/0xd0
...
It was triggered by dereferencing a bad pointer (RDI) immediately after
a VMware hypercall for VMWARE_CMD_ABSPOINTER_DATA in the vmmouse driver:
ffffffff82135070 <vmware_hypercall4.constprop.0>:
...
ffffffff821350ac: b8 68 58 4d 56 mov $0x564d5868,%eax
ffffffff821350b1: b9 27 00 00 00 mov $0x27,%ecx
ffffffff821350b6: 31 d2 xor %edx,%edx
ffffffff821350b8: bb 04 00 00 00 mov $0x4,%ebx
ffffffff821350bd: 66 ba 58 56 mov $0x5658,%dx
ffffffff821350c1: ed in (%dx),%eax <--
hypercall
ffffffff821350c2: 89 1f mov %ebx,(%rdi) <--
crash
Reading the kernel disassembly shows that RDI should contain the value
of a valid kernel stack address here (0xff5eeb3240003e54). Instead it
contains 0x40003e54, suggesting the hypervisor cleared the upper 32
bits.
And indeed, Alexey discovered that QEMU's vmmouse_get_data() and
vmmouse_set_data() are only saving/restoring the lower 32 bits, while
clearing the upper 32. Fix that by changing the type of the saved data
array from uint32_t to uint64_t.
Fixes: 548df2acc6fc ("VMMouse Emulation, by Anthony Liguori.")
Reported-by: Justin Forbes <[email protected]>
Debugged-by: Alexey Makhalov <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Link:
https://lore.kernel.org/r/c508fc1d4a4ccd8c9fb1e51b71df089e31115a53.1770309998.git.jpoim...@kernel.org
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3293
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 48c8916aec4319efc60324d9d971831a8a1d6350)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 17ec370a79041e63a6a4807fde84963aa617ac6a
https://github.com/qemu/qemu/commit/17ec370a79041e63a6a4807fde84963aa617ac6a
Author: Bernhard Beschow <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/i386/emulate/x86_decode.c
Log Message:
-----------
target/i386/emulate/x86_decode: Fix compiler warning
When compiling for i386-softmmu under MSYS2, GCC emits the following warning:
In function 'get_reg_val',
inlined from 'calc_modrm_operand64' at
../src/target/i386/emulate/x86_decode.c:1796:15:
../src/target/i386/emulate/x86_decode.c:1703:5: error: 'memcpy' forming
offset [4, 7] is out of the bounds [0, 4] of object 'val' with type
'target_ulong' {aka 'unsigned int'} [-Werror=array-bounds=]
1703 | memcpy(&val,
| ^~~~~~~~~~~~
1704 | get_reg_ref(env, reg, rex_present, is_extended, size),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1705 | size);
| ~~~~~
../src/target/i386/emulate/x86_decode.c: In function 'calc_modrm_operand64':
../src/target/i386/emulate/x86_decode.c:1702:18: note: 'val' declared here
1702 | target_ulong val = 0;
| ^~~
In the calc_modrm_operand64() case the compiler sees size == 8 to be mem-copied
to a target_ulong variable which is only 4 bytes wide in case of i386-softmmu.
Note that when size != 1, get_reg_ref() always returns a pointer to an 8 byte
register, regardless of the target_ulong size. Fix the compiler warning by
always providing 8 bytes of storage by means of uint64_t.
Fixes: 77a2dba45cc9 ("target/i386/emulate: stop overloading decode->op[N].ptr")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Mohamed Mediouni <[email protected]>
Reviewed-by: Wei Liu (Microsoft) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit c86bca1671e9e4161e2a93d73514384de510bbf3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 32c1fc948e5b06beb368d32fe5f99b3fb039c149
https://github.com/qemu/qemu/commit/32c1fc948e5b06beb368d32fe5f99b3fb039c149
Author: Bernhard Beschow <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/i386/hvf/x86_mmu.c
Log Message:
-----------
target/i386/hvf/x86_mmu: Fix compiler warning
When reusing the code in WHPX, GCC emits the following warning when compiling
for i386-softmmu under MSYS2:
In file included from ../src/target/i386/emulate/x86_mmu.c:20:
../src/target/i386/emulate/x86_mmu.c: In function 'vmx_write_mem':
../src/target/i386/emulate/x86_mmu.c:251:25: error: format '%llx' expects
argument of type 'long long unsigned int', but argument 3 has type
'target_ulong' {aka 'unsigned int'} [-Werror=format=]
251 | VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__,
gva);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
|
|
|
target_ulong {aka unsigned int}
../src/target/i386/emulate/panic.h:34:12: note: in definition of macro
'VM_PANIC_EX'
34 | printf(__VA_ARGS__); \
| ^~~~~~~~~~~
../src/target/i386/emulate/x86_mmu.c:251:48: note: format string is defined
here
251 | VM_PANIC_EX("%s: mmu_gva_to_gpa %llx failed\n", __func__,
gva);
| ~~~^
| |
| long long unsigned int
| %x
Fix the warning by reusing the target-specific macro TARGET_FMT_lx which exists
for this exact purpose.
Fixes: c97d6d2cdf97 ("i386: hvf: add code base from Google's QEMU repository")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Mohamed Mediouni <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Wei Liu (Microsoft) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 529e5e7643078e19d65e694f51cad64be49090ab)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 438b752c76a7aff3e930d8ddb096ba555c9bcc67
https://github.com/qemu/qemu/commit/438b752c76a7aff3e930d8ddb096ba555c9bcc67
Author: Bernhard Beschow <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/i386/emulate/x86_decode.c
Log Message:
-----------
target/i386/emulate/x86_decode: Actually use stream in
decode_instruction_stream()
Compared to decode_instruction(), decode_instruction_stream() has an additional
stream parameter which avoids some guest memory accesses during instruction
decoding. Both functions defer the actual work to decode_opcode() which would
set the stream pointer to zero such that decode_instruction_stream() essentially
behaved like decode_instruction(). Given that all callers of
decode_instruction_stream() properly zero-initialize the decode parameter, the
memset() call can be moved into decode_instruction() which is the only other
user of decode_opcode(). This preserves the non-zero stream pointer which
avoids extra guest memory accesses.
Fixes: 1e25327b244a ("target/i386/emulate: Allow instruction decoding from
stream")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Mohamed Mediouni <[email protected]>
Reviewed-by: Wei Liu (Microsoft) <[email protected]>
Tested-by: Magnus Kulke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 1b93832f55927b1b76a6587ca75a5a35676188de)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0deef852924f58c429b886eb4a2ca9ce0b8b381c
https://github.com/qemu/qemu/commit/0deef852924f58c429b886eb4a2ca9ce0b8b381c
Author: Peter Maydell <[email protected]>
Date: 2026-03-02 (Mon, 02 Mar 2026)
Changed paths:
M target/ppc/translate/ppe-impl.c.inc
Log Message:
-----------
target/ppc/translate: Fix TCG debug assert translating CLRBWIBC
The test case in the ppe42 functional test triggers a TCG debug
assertion, which causes the test to fail in an --enable-debug
build or when the sanitizers are enabled:
#6 0x00007ffff4a3b517 in __assert_fail
(assertion=0x5555562e7589 "!temp_readonly(ots)", file=0x5555562e5b23
"../../tcg/tcg.c", line=4928, function=0x5555562e8900 <__PRETTY_FUNCTION__.23>
"tcg_reg_alloc_mov") at ./assert/assert.c:105
#7 0x0000555555cc2189 in tcg_reg_alloc_mov (s=0x7fff60000b70,
op=0x7fff600126f8) at ../../tcg/tcg.c:4928
#8 0x0000555555cc74e0 in tcg_gen_code (s=0x7fff60000b70, tb=0x7fffa802f540,
pc_start=4294446080) at ../../tcg/tcg.c:6667
#9 0x0000555555d02abe in setjmp_gen_code
(env=0x555556cbe610, tb=0x7fffa802f540, pc=4294446080,
host_pc=0x7fffeea00c00, max_insns=0x7fffee9f9d74, ti=0x7fffee9f9d90)
at ../../accel/tcg/translate-all.c:257
#10 0x0000555555d02d75 in tb_gen_code (cpu=0x555556cba590, s=...) at
../../accel/tcg/translate-all.c:325
#11 0x0000555555cf5922 in cpu_exec_loop (cpu=0x555556cba590, sc=0x7fffee9f9ee0)
at ../../accel/tcg/cpu-exec.c:970
#12 0x0000555555cf5aae in cpu_exec_setjmp (cpu=0x555556cba590,
sc=0x7fffee9f9ee0) at ../../accel/tcg/cpu-exec.c:1016
#13 0x0000555555cf5b4b in cpu_exec (cpu=0x555556cba590) at
../../accel/tcg/cpu-exec.c:1042
#14 0x0000555555d1e7ab in tcg_cpu_exec (cpu=0x555556cba590) at
../../accel/tcg/tcg-accel-ops.c:82
#15 0x0000555555d1ff97 in rr_cpu_thread_fn (arg=0x555556cba590) at
../../accel/tcg/tcg-accel-ops-rr.c:285
#16 0x00005555561586c9 in qemu_thread_start (args=0x555556ee3c90) at
../../util/qemu-thread-posix.c:393
#17 0x00007ffff4a9caa4 in start_thread (arg=<optimized out>) at
./nptl/pthread_create.c:447
#18 0x00007ffff4b29c6c in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
This can be reproduced "by hand":
./build/clang/qemu-system-ppc -display none -vga none \
-machine ppe42_machine -serial stdio \
-device
loader,file=$HOME/.cache/qemu/download/03c1ac0fb7f6c025102a02776a93b35101dae7c14b75e4eab36a337e39042ea8
\
-device loader,addr=0xfff80040,cpu-num=0
(assuming you have the image file from the functional test
in your local cache).
This happens for this input:
IN:
0xfff80c00: 07436004 .byte 0x07, 0x43, 0x60, 0x04
which generates (among other things):
not_i32 $0x80000,$0x80000
which the TCG optimization pass turns into:
mov_i32 $0x80000,$0xfff7ffff dead: 1 pref=0xffff
and where we then assert because we tried to write to a constant.
This happens for the CLRBWIBC instruction which ends up in
do_mask_branch() with rb_is_gpr false and invert true. In this case
we will generate code that sets mask to a tcg_constant_tl() but then
uses it as the LHS in tcg_gen_not_tl().
Fix the assertion by doing the invert in the translate time C code
for the "mask is constant" case.
Cc: [email protected]
Fixes: f7ec91c23906 ("target/ppc: Add IBM PPE42 special instructions")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Glenn Miles <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Harsh Prateek Bora <[email protected]>
(cherry picked from commit 78c6b6010ce7cfa54874dda514e694640b76f1e4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 68e031345a022643896b3f4f95391cecdac592fe
https://github.com/qemu/qemu/commit/68e031345a022643896b3f4f95391cecdac592fe
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M include/io/task.h
M io/channel-tls.c
M io/channel-websock.c
M io/task.c
M tests/unit/test-io-task.c
Log Message:
-----------
io: separate freeing of tasks from marking them as complete
The original design of QIOTask was intended to simplify lifecycle
management by automatically freeing it when the task was marked as
complete. This overlooked the fact that when a QIOTask is used in
combination with a GSource, there may be times when the source
callback is never invoked. This is typically when a GSource is
released before any I/O event arrives. In such cases it is not
desirable to mark a QIOTask as complete, but it still needs to be
freed. To satisfy this, the task must be released manually.
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 163cd0ae1182e67509b271f244a73dfd938337b9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f8943633a91f36b4f7372cd8598209425189df4a
https://github.com/qemu/qemu/commit/f8943633a91f36b4f7372cd8598209425189df4a
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M io/channel-tls.c
Log Message:
-----------
io: fix cleanup for TLS I/O source data on cancellation
The TLS code will create a GSource for tracking completion of the
handshake process, passing a QIOChannelTLSData struct that contains
various data items. The data struct is freed by the callback when
it completes, which means when a source is cancelled, nothing is
free'ing the data struct or its contents.
Switch to provide a data free callback to the GSource, which ensures
the QIOChannelTLSData struct is always freed even when the main event
callback never fires.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit d39d0f3acdd7c1bb275db7e97b511f98254ecd9f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e944f36993223b4a2f52759941ef7dee4a3a428d
https://github.com/qemu/qemu/commit/e944f36993223b4a2f52759941ef7dee4a3a428d
Author: Daniel P. Berrangé <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M io/channel-websock.c
Log Message:
-----------
io: fix cleanup for websock I/O source data on cancellation
The websock code will create a GSource for tracking completion of the
handshake process, passing a QIOTask which is freed by the callback
when it completes, which means when a source is cancelled, nothing is
free'ing the task.
Switch to provide a data free callback to the GSource, which ensures
the QIOTask is always freed even when the main event callback never
fires.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/3114
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 9545c059f77e3f814fcbaba83203572ea655c50e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 52cb65f9a6a9a7399c545d9f80b5ef40f0cc33af
https://github.com/qemu/qemu/commit/52cb65f9a6a9a7399c545d9f80b5ef40f0cc33af
Author: Peter Maydell <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Don't allow negative-length packets
The smc91c111 data frame format in memory (figure 8-1 in the
datasheet) includes a "byte count" field which is intended to be the
total size of the data frame, including not just the packet data but
also the leading and trailing information like the status word and
the byte count field itself. It is therefore possible for the guest
to set this to a value so small that the leading and trailing fields
won't fit and the packet has effectively a negative area.
We weren't checking for this, with the result that when we subtract 6
from the length to get the length of the packet proper we end up with
a negative length, which is then inconsistently handled in the
qemu_send_packet() code such that we can try to transmit a very large
amount of data and read off the end of the device's data array.
Treat excessively small length values the same way we do excessively
large values. As with the oversized case, the datasheet does not
describe what happens for this software error case, and there is no
relevant tx error condition for this, so we just log and drop the
packet.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3304
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit d8e19f8042dcaff8e077292209c8196acb150bdd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 86b5130fefbe476f3c0a85b9e136f9e3fd518689
https://github.com/qemu/qemu/commit/86b5130fefbe476f3c0a85b9e136f9e3fd518689
Author: Halil Oktay (oblivionsage) <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/vmdk.c
Log Message:
-----------
block/vmdk: fix OOB read in vmdk_read_extent()
Bounds check for marker.size doesn't account for the 12-byte marker
header, allowing zlib to read past the allocated buffer.
Move the check inside the has_marker block and subtract the marker size.
Fixes: CVE-2026-2243
Reported-by: Halil Oktay (oblivionsage) <[email protected]>
Signed-off-by: Halil Oktay (oblivionsage) <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit cfda94eddb6c9c49b66461c950b22845a46a75c9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 11589707ec8ad08a9e45ea9b43d1d800a14d1670
https://github.com/qemu/qemu/commit/11589707ec8ad08a9e45ea9b43d1d800a14d1670
Author: Antoine Damhet <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl: fix concurrent completion handling
curl_multi_check_completion would bail upon the first completed
transfer even if more completion messages were available thus leaving
some in flight IOs stuck.
Rework a bit the loop to make the iterations clearer and drop the breaks.
The original hang can be somewhat reproduced with the following command:
$ qemu-img convert -p -m 16 -O qcow2 -c --image-opts \
'file.driver=https,file.url=https://scaleway.testdebit.info/10G.iso,file.readahead=1M'
\
/tmp/test.qcow2
Fixes: 1f2cead32443 ("curl: Ensure all informationals are checked for
completion")
Cc: [email protected]
Signed-off-by: Antoine Damhet <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 6f7b0a23a6ea0cc72ad222ab37936248d99d4256)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 61f14858c1599e387aec3c3612b63a49e84078a5
https://github.com/qemu/qemu/commit/61f14858c1599e387aec3c3612b63a49e84078a5
Author: Kevin Wolf <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/mirror.c
Log Message:
-----------
mirror: Fix missed dirty bitmap writes during startup
Currently, mirror disables the block layer's dirty bitmap before its own
replacement is working. This means that during startup, there is a
window in which the allocation status of blocks in the source has
already been checked, but new writes coming in aren't tracked yet,
resulting in a corrupted copy:
1. Dirty bitmap is disabled in mirror_start_job()
2. Some request are started in mirror_top_bs while s->job == NULL
3. mirror_dirty_init() -> bdrv_co_is_allocated_above() runs and because
the request hasn't completed yet, the block isn't allocated
4. The request completes, still sees s->job == NULL and skips the
bitmap, and nothing else will mark it dirty either
One ingredient is that mirror_top_opaque->job is only set after the
job is fully initialized. For the rationale, see commit 32125b1460
("mirror: Fix access of uninitialised fields during start").
Fix this by giving mirror_top_bs access to dirty_bitmap and enabling it
to track writes from the beginning. Disabling the block layer's tracking
and enabling the mirror_top_bs one happens in a drained section, so
there is no danger of races with in-flight requests any more. All of
this happens well before the block allocation status is checked, so we
can be sure that no writes will be missed.
Cc: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/3273
Fixes: 32125b14606a ('mirror: Fix access of uninitialised fields during start')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Tested-by: Jean-Louis Dupond <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 0f51f9c3420b31bb383e456dd7bf24d3056eeb73)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 43e60c88f1d0d9c7b2da766723d34038217dde0b
https://github.com/qemu/qemu/commit/43e60c88f1d0d9c7b2da766723d34038217dde0b
Author: Dmitry Guryanov <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/throttle-groups.c
M include/block/throttle-groups.h
Log Message:
-----------
block/throttle-groups: fix deadlock with iolimits and muliple iothreads
Details: https://gitlab.com/qemu-project/qemu/-/issues/3144
The function schedule_next_request is called with tg->lock held and
it may call throttle_group_co_restart_queue, which takes
tgm->throttled_reqs_lock, qemu_co_mutex_lock may leave current
coroutine if other iothread has taken the lock. If the next
coroutine will call throttle_group_co_io_limits_intercept - it
will try to take the mutex tg->lock which will never be released.
Here is the backtrace of the iothread:
Thread 30 (Thread 0x7f8aad1fd6c0 (LWP 24240) "IO iothread2"):
#0 futex_wait (futex_word=0x5611adb7d828, expected=2, private=0) at
../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0x5611adb7d828, private=0) at
lowlevellock.c:49
#2 0x00007f8ab5a97501 in lll_mutex_lock_optimized (mutex=0x5611adb7d828) at
pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=0x5611adb7d828) at pthread_mutex_lock.c:93
#4 0x00005611823f5482 in qemu_mutex_lock_impl (mutex=0x5611adb7d828,
file=0x56118289daca "../block/throttle-groups.c", line=372) at
../util/qemu-thread-posix.c:94
#5 0x00005611822b0b39 in throttle_group_co_io_limits_intercept
(tgm=0x5611af1bb4d8, bytes=4096, direction=THROTTLE_READ) at
../block/throttle-groups.c:372
#6 0x00005611822473b1 in blk_co_do_preadv_part (blk=0x5611af1bb490,
offset=15972311040, bytes=4096, qiov=0x7f8aa4000f98, qiov_offset=0,
flags=BDRV_REQ_REGISTERED_BUF) at ../block/block-backend.c:1354
#7 0x0000561182247fa0 in blk_aio_read_entry (opaque=0x7f8aa4005910) at
../block/block-backend.c:1619
#8 0x000056118241952e in coroutine_trampoline (i0=-1543497424, i1=32650) at
../util/coroutine-ucontext.c:175
#9 0x00007f8ab5a56f70 in ?? () at
../sysdeps/unix/sysv/linux/x86_64/__start_context.S:66 from
target:/lib64/libc.so.6
#10 0x00007f8aad1ef190 in ?? ()
#11 0x0000000000000000 in ?? ()
The lock is taken in line 386:
(gdb) p tg.lock
$1 = {lock = {__data = {__lock = 2, __count = 0, __owner = 24240, __nusers = 1,
__kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = "\002\000\000\000\000\000\000\000\260^\000\000\001", '\000'
<repeats 26 times>, __align = 2}, file = 0x56118289daca
"../block/throttle-groups.c",
line = 386, initialized = true}
The solution is to use tg->lock to protect both ThreadGroup fields and
ThrottleGroupMember.throttled_reqs. It doesn't seem to be possible
to use separate locks because we need to first manipulate ThrottleGroup
fields, then schedule next coroutine using throttled_reqs and after than
update token field from ThrottleGroup depending on the throttled_reqs
state.
Signed-off-by: Dmitry Guryanov <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit d4816177654d59e26ce212c436513f01842eb410)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ca8b13eb043c206fe374d5777186c433993cd862
https://github.com/qemu/qemu/commit/ca8b13eb043c206fe374d5777186c433993cd862
Author: Kevin Wolf <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M monitor/monitor.c
M qapi/block-core.json
Log Message:
-----------
block: Never drop BLOCK_IO_ERROR with action=stop for rate limiting
Commit 2155d2dd introduced rate limiting for BLOCK_IO_ERROR to emit an
event only once a second. This makes sense for cases in which the guest
keeps running and can submit more requests that would possibly also fail
because there is a problem with the backend.
However, if the error policy is configured so that the VM is stopped on
errors, this is both unnecessary because stopping the VM means that the
guest can't issue more requests and in fact harmful because stopping the
VM is an important state change that management tools need to keep track
of even if it happens more than once in a given second. If an event is
dropped, the management tool would see a VM randomly going to paused
state without an associated error, so it has a hard time deciding how to
handle the situation.
This patch disables rate limiting for action=stop by not relying on the
event type alone any more in monitor_qapi_event_queue_no_reenter(), but
checking action for BLOCK_IO_ERROR, too. If the error is reported to the
guest or ignored, the rate limiting stays in place.
Fixes: 2155d2dd7f73 ('block-backend: per-device throttling of BLOCK_IO_ERROR
reports')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 544ddbb6373d61292a0e2dc269809cd6bd5edec6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8b851e5bb114f795e8f4ffd7712034a45c24dfad
https://github.com/qemu/qemu/commit/8b851e5bb114f795e8f4ffd7712034a45c24dfad
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/nfs.c
Log Message:
-----------
block/nfs: Do not enter coroutine from CB
The reasoning I gave for why it would be safe to call aio_co_wake()
despite holding the mutex was wrong: It is true that the current request
will not re-acquire the mutex, but a subsequent request in the same
coroutine can. Because the mutex is a non-coroutine mutex, this will
result in a deadlock.
Therefore, we must either not enter the coroutine here (only scheduling
it), or release the mutex around aio_co_wake(). I opt for the former,
as it is the behavior prior to the offending commit, and so seems safe
to do.
Fixes: deb35c129b859b9bec70fd42f856a0b7c1dc6e61
("nfs: Run co BH CB in the coroutine’s AioContext")
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/2622#note_2965097035
Cc: [email protected]
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 1d6610099bd7fc159626a38e60a3c84343ff67f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f9b1537744b92e45d99648556b934aaaf36b7c82
https://github.com/qemu/qemu/commit/f9b1537744b92e45d99648556b934aaaf36b7c82
Author: Jens Axboe <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M util/aio-posix.c
Log Message:
-----------
aio-posix: notify main loop when SQEs are queued
When a vCPU thread handles MMIO (holding BQL), aio_co_enter() runs the
block I/O coroutine inline on the vCPU thread because
qemu_get_current_aio_context() returns the main AioContext when BQL is
held. The coroutine calls luring_co_submit() which queues an SQE via
fdmon_io_uring_add_sqe(), but the actual io_uring_submit() only happens
in gsource_prepare() on the main loop thread.
Since the coroutine ran inline (not via aio_co_schedule()), no BH is
scheduled and aio_notify() is never called. The main loop remains asleep
in ppoll() with up to a 499ms timeout, leaving the SQE unsubmitted until
the next timer fires.
Fix this by calling aio_notify() after queuing the SQE. This wakes the
main loop via the eventfd so it can run gsource_prepare() and submit the
pending SQE promptly.
This is a generic fix that benefits all devices using aio=io_uring.
Without it, AHCI/SATA devices see MUCH worse I/O latency since they use
MMIO (not ioeventfd like virtio) and have no other mechanism to wake the
main loop after queuing block I/O.
This is usually a bit hard to detect, as it also relies on the ppoll
loop not waking up for other activity, and micro benchmarks tend not to
see it because they don't have any real processing time. With a
synthetic test case that has a few usleep() to simulate processing of
read data, it's very noticeable. The below example reads 128MB with
O_DIRECT in 128KB chunks in batches of 16, and has a 1ms delay before
each batch submit, and a 1ms delay after processing each completion.
Running it on /dev/sda yields:
time sudo ./iotest /dev/sda
________________________________________________________
Executed in 25.76 secs fish external
usr time 6.19 millis 783.00 micros 5.41 millis
sys time 12.43 millis 642.00 micros 11.79 millis
while on a virtio-blk or NVMe device we get:
time sudo ./iotest /dev/vdb
________________________________________________________
Executed in 1.25 secs fish external
usr time 1.40 millis 0.30 millis 1.10 millis
sys time 17.61 millis 1.43 millis 16.18 millis
time sudo ./iotest /dev/nvme0n1
________________________________________________________
Executed in 1.26 secs fish external
usr time 6.11 millis 0.52 millis 5.59 millis
sys time 13.94 millis 1.50 millis 12.43 millis
where the latter are consistent. If we run the same test but keep the
socket for the ssh connection active by having activity there, then
the sda test looks as follows:
time sudo ./iotest /dev/sda
________________________________________________________
Executed in 1.23 secs fish external
usr time 2.70 millis 39.00 micros 2.66 millis
sys time 4.97 millis 977.00 micros 3.99 millis
as now the ppoll loop is woken all the time anyway.
After this fix, on an idle system:
time sudo ./iotest /dev/sda
________________________________________________________
Executed in 1.30 secs fish external
usr time 2.14 millis 0.14 millis 2.00 millis
sys time 16.93 millis 1.16 millis 15.76 millis
Signed-off-by: Jens Axboe <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
[Generalize the comment since this applies to all vCPU thread activity,
not just coroutines, as suggested by Kevin Wolf <[email protected]>.
--Stefan]
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 2ae361ef1d7d526b07ff88d854552e2d009bfb1b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a40b3f664c330bae30b7d9d55028aba6ef75d95d
https://github.com/qemu/qemu/commit/a40b3f664c330bae30b7d9d55028aba6ef75d95d
Author: Jens Axboe <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M util/fdmon-io_uring.c
Log Message:
-----------
fdmon-io_uring: check CQ ring directly in gsource_check
gsource_check() only looks at the ppoll revents for the io_uring fd,
but CQEs can be posted during gsource_prepare()'s io_uring_submit()
call via kernel task_work processing on syscall exit. These completions
are already sitting in the CQ ring but the ring fd may not be signaled
yet, causing gsource_check() to return false.
Add a fallback io_uring_cq_ready() check so completions that arrive
during submission are dispatched immediately rather than waiting for
the next ppoll() cycle.
Signed-off-by: Jens Axboe <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 961fcc0f22768e7c3432fc645b93dc7cd4932fae)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0c5199e52b7cd4c3253ad76cb3ad0faa22acb8ca
https://github.com/qemu/qemu/commit/0c5199e52b7cd4c3253ad76cb3ad0faa22acb8ca
Author: Dmitry Osipenko <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M hw/display/virtio-gpu-virgl.c
M hw/display/virtio-gpu.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio-gpu: Ensure BHs are invoked only from main-loop thread
QEMU's display GL core is tied to main-loop thread and virtio-gpu
interacts with display while processing GPU commands. Virtio-gpu BHs
work in generic AIO context that can be invoked on vCPU thread, while
GL and UI toolkits are bound to the main-loop thread.
Make virtio-gpu BHs use iohandler AIO context that is handled in a
main-loop thread only.
0 SDL_GL_MakeCurrent() (libSDL3)
1 SDL_GL_MakeCurrent_REAL() (libSDL2)
2 sdl2_gl_make_context_current() (ui/sdl2-gl.c:201)
3 make_current() (virglrenderer.c:639)
4 vrend_finish_context_switch() (vrend_renderer.c:11630)
5 vrend_hw_switch_context() (vrend_renderer.c:11613)
6 vrend_renderer_force_ctx_0() (vrend_renderer.c:12986)
7 virgl_renderer_force_ctx_0() (virglrenderer.c:460)
8 virtio_gpu_virgl_process_cmd() (virtio-gpu-virgl.c:1013)
9 virtio_gpu_process_cmdq() (virtio-gpu.c:1050)
10 virtio_gpu_gl_handle_ctrl() (virtio-gpu-gl.c:86)
11 aio_bh_poll() (util/async.c)
12 aio_poll() (util/aio-posix.c)
13 blk_pwrite() (block/block-gen.c:1985)
14 pflash_update() (pflash_cfi01.c:396)
15 pflash_write() (pflash_cfi01.c:541)
16 memory_region_dispatch_write() (system/memory.c:1554)
17 flatview_write() (system/physmem.c:3333)
18 address_space_write() (system/physmem.c:3453)
19 kvm_cpu_exec() (accel/kvm/kall-all.c:3248)
20 kvm_vcpu_thread_fn() (accel/kvm/kaccel-ops.c:53)
Cc: [email protected]
Signed-off-by: Dmitry Osipenko <[email protected]>
Message-ID: <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
(cherry picked from commit 235f9b36383e4cc7a790bca51eddbe38edd5438c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d9dfd5f425684702b09e0fe135bd3a8041f98b9f
https://github.com/qemu/qemu/commit/d9dfd5f425684702b09e0fe135bd3a8041f98b9f
Author: Peter Maydell <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M hw/net/trace-events
M hw/net/xilinx_ethlite.c
Log Message:
-----------
hw/net/xilinx_ethlite: Check for oversized TX packets
The xilinx_ethlite network device wasn't checking that the TX packet
size set by the guest was within the size of its dual port RAM, with
the effect that the guest could get it to read off the end of the RAM
block.
Check the length. There is no provision in this very simple device
for reporting errors, so as with various RX errors we just report via
tracepoint.
This lack of length check has been present since the device was first
introduced, though the code implementing the tx path has changed
somewhat since then.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3317
Fixes: b43848a1005ce ("xilinx: Add ethlite emulation")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Edgar E. Iglesias <[email protected]>
Message-ID: <[email protected]>
[PMD: renamed size -> tx_size to avoid shadow=compatible-local error]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 6595a8d5d17ea1716ddafb34455ec2b29381e232)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82d83d29bd419a416d3aacf820e46a664030ec7e
https://github.com/qemu/qemu/commit/82d83d29bd419a416d3aacf820e46a664030ec7e
Author: Bingwu Zhang <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M linux-user/mmap.c
Log Message:
-----------
linux-user: Deal with mmap where start > reserved_va
Fixes: 4c13048e02d9 ("linux-user: Use page_find_range_empty for
mmap_find_vma_reserved")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3310
Signed-off-by: Bingwu Zhang <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
(cherry picked from commit f2813e13fe910e01127271a87177a477b9438bc6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ed18bbbc117bc993af97fa7109b36e62847f58e6
https://github.com/qemu/qemu/commit/ed18bbbc117bc993af97fa7109b36e62847f58e6
Author: Bingwu Zhang <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M bsd-user/mmap.c
Log Message:
-----------
bsd-user: Deal with mmap where start > reserved_va
Fixes: f12294b5bd21 ("bsd-user: Use page_find_range_empty for
mmap_find_vma_reserved")
Signed-off-by: Bingwu Zhang <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
Reviewed-by: Warner Losh <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
(cherry picked from commit e8e7d1f97785be2fd81fc520e0c7b9d228c10a56)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2481744d961121e311381b5781a8d35f628722f2
https://github.com/qemu/qemu/commit/2481744d961121e311381b5781a8d35f628722f2
Author: Bingwu Zhang <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M tests/tcg/multiarch/test-mmap.c
Log Message:
-----------
tests/tcg/multiarch/test-mmap: Check mmaps beyond reserved_va
Unfixed mmap calls where start > reserved_va or the max guest addr
should have a valid result.
Signed-off-by: Bingwu Zhang <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
(cherry picked from commit c865b6bce5d0c882b86fb7c3512174cdaf235017)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6f6bdf376347475cc0f207ef142e5122fd36fb22
https://github.com/qemu/qemu/commit/6f6bdf376347475cc0f207ef142e5122fd36fb22
Author: Andreas Schwab <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M linux-user/ioctls.h
Log Message:
-----------
linux-user: fix TIOCGSID ioctl
TIOCGSID is IOC_R, not IOC_W.
Signed-off-by: Andreas Schwab <[email protected]>
Reviewed-by: Helge Deller <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
(cherry picked from commit 6a1221614fd9344a22cafea78e48d6ded95f317d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a69152d2571c69a27349ba31cd45fc2d15738950
https://github.com/qemu/qemu/commit/a69152d2571c69a27349ba31cd45fc2d15738950
Author: Peter Maydell <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M hw/net/npcm_gmac.c
M include/hw/net/npcm_gmac.h
Log Message:
-----------
hw/net/npcm_gmac: Catch accesses off the end of the register array
In the npcm_gmac device, we create the iomem MemoryRegion with
a size of 8KB, but NPCM_GMAC_NR_REGS is only 0x1060 / 4. This
means there's a range of offsets that the guest can access
that don't have gmac->regs[] entries. We weren't catching this,
so the guest could get us to index off the end of the regs array.
Catch and log these invalid accesses.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3316
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 550391c7134d295d73b2b0e7a1111a922b78c13c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f07f64c3d847d19940b515a9756c4e1ecedb636c
https://github.com/qemu/qemu/commit/f07f64c3d847d19940b515a9756c4e1ecedb636c
Author: Peter Maydell <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M hw/core/qdev.c
M hw/virtio/virtio.c
M include/hw/qdev-core.h
Log Message:
-----------
hw: Make qdev_get_printable_name() consistently return freeable string
The current implementation of qdev_get_printable_name() sometimes
returns a string that must not be freed (vdev->id or the fixed
fallback string "<unknown device>" and sometimes returns a string
that must be freed (the return value of qdev_get_dev_path()). This
forces callers to leak the string in the "must be freed" case.
Make the function consistent that it always returns a string that
the caller must free, and make the three callsites free it.
This fixes leaks like this that show up when running "make check"
with the address sanitizer enabled:
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x5561de21f293 in malloc
(/home/pm215/qemu/build/san/qemu-system-i386+0x1a2d293) (BuildId:
6d6fad7130fd5c8dbbc03401df554f68b8034936)
#1 0x767ad7a82ac9 in g_malloc
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62ac9) (BuildId:
116e142b9b52c8a4dfd403e759e71ab8f95d8bb3)
#2 0x5561deaf34f2 in pcibus_get_dev_path
/home/pm215/qemu/build/san/../../hw/pci/pci.c:2792:12
#3 0x5561df9d8830 in qdev_get_printable_name
/home/pm215/qemu/build/san/../../hw/core/qdev.c:431:24
#4 0x5561deebdca2 in virtio_init_region_cache
/home/pm215/qemu/build/san/../../hw/virtio/virtio.c:298:17
#5 0x5561df05f842 in memory_region_write_accessor
/home/pm215/qemu/build/san/../../system/memory.c:491:5
#6 0x5561df05ed1b in access_with_adjusted_size
/home/pm215/qemu/build/san/../../system/memory.c:567:18
#7 0x5561df05e3fa in memory_region_dispatch_write
/home/pm215/qemu/build/san/../../system/memory.c
#8 0x5561df0aa805 in address_space_stm_internal
/home/pm215/qemu/build/san/../../system/memory_ldst.c.inc:85:13
#9 0x5561df0bcad3 in qtest_process_command
/home/pm215/qemu/build/san/../../system/qtest.c:480:13
Cc: [email protected]
Fixes: e209d4d7a31b9 ("virtio: improve virtqueue mapping error messages")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 1e3e1d51e20e8b38efa089bf54b5ee2cbbcca221)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 67638dba7acd9f595a9e0e846d6085cfab4ff0e3
https://github.com/qemu/qemu/commit/67638dba7acd9f595a9e0e846d6085cfab4ff0e3
Author: rail5 <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M target/loongarch/tcg/tcg_cpu.c
Log Message:
-----------
target/loongarch: Avoid recursive PNX exception on CSR_BADI fetch
loongarch_cpu_do_interrupt() updates CSR_BADI by fetching the faulting
instruction with cpu_ldl_code_mmu().
For a PNX exception (instruction fetch prohibited by NX), fetching the
instruction at env->pc will fault with PNX again. This can lead to an
infinite exception loop.
Treat PNX like other instruction-fetch exceptions (PIF/ADEF) and do not
update CSR_BADI for it.
Fixes: 410dfbf620a ("target/loongarch: Move TCG specified functions to
tcg_cpu.c")
Cc: [email protected]
Signed-off-by: rail5 (Andrew S. Rightenburg) <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(cherry picked from commit db2325f79481fab87211e5a287580d753f582cb8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 03455e1e0a69c34f63835547971fac551a5ba85a
https://github.com/qemu/qemu/commit/03455e1e0a69c34f63835547971fac551a5ba85a
Author: rail5 <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M target/loongarch/cpu.c
M target/loongarch/cpu.h
M target/loongarch/tcg/tlb_helper.c
Log Message:
-----------
target/loongarch: Preserve PTE permission bits in LDPTE
The LDPTE helper loads a page table entry (or huge page entry) from guest
memory and currently applies the PALEN mask to the whole 64-bit value.
That mask is intended to constrain the physical address bits, but masking
the full entry also clears upper permission bits in the PTE, including NX
(bit 62). As a result, LoongArch TCG can incorrectly allow instruction
fetches from NX mappings when translation is driven through software
page-walk.
Fix this by masking only the PPN/address field with PALEN while preserving
permission bits, and by clearing any non-architectural (software) bits
using a hardware PTE mask. LDDIR is unchanged since it returns the base
address of the next page table level.
Reported at: https://gitlab.com/qemu-project/qemu/-/issues/3319
Fixes: 56599a705f2 ("target/loongarch: Introduce loongarch_palen_mask()")
Cc: [email protected]
Signed-off-by: rail5 (Andrew S. Rightenburg) <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(cherry picked from commit 2d877bc02a3b94998cbdd784d194c173d308a98a)
(Mjt: backport to 10.2.x which lacks v10.2.0-1568-g56599a705f
"target/loongarch: Introduce loongarch_palen_mask()")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 39b1f5e944f4c0141f8cfcb010b27cf2a9b6dcdd
https://github.com/qemu/qemu/commit/39b1f5e944f4c0141f8cfcb010b27cf2a9b6dcdd
Author: Hanna Czenczek <[email protected]>
Date: 2026-03-11 (Wed, 11 Mar 2026)
Changed paths:
M block/export/fuse.c
Log Message:
-----------
fuse: Copy write buffer content before polling
aio_poll() in I/O functions can lead to nested read_from_fuse_export()
calls, overwriting the request buffer's content. The only function
affected by this is fuse_write(), which therefore must use a bounce
buffer or corruption may occur.
Note that in addition we do not know whether libfuse-internal structures
can cope with this nesting, and even if we did, we probably cannot rely
on it in the future. This is the main reason why we want to remove
libfuse from the I/O path.
I do not have a good reproducer for this other than:
$ dd if=/dev/urandom of=image bs=1M count=4096
$ dd if=/dev/zero of=copy bs=1M count=4096
$ touch fuse-export
$ qemu-storage-daemon \
--blockdev file,node-name=file,filename=copy \
--export \
fuse,id=exp,node-name=file,mountpoint=fuse-export,writable=true \
&
Other shell:
$ qemu-img convert -p -n -f raw -O raw -t none image fuse-export
$ killall -SIGINT qemu-storage-daemon
$ qemu-img compare image copy
Content mismatch at offset 0!
(The -t none in qemu-img convert is important.)
I tried reproducing this with throttle and small aio_write requests from
another qemu-io instance, but for some reason all requests are perfectly
serialized then.
I think in theory we should get parallel writes only if we set
fi->parallel_direct_writes in fuse_open(). In fact, I can confirm that
if we do that, that throttle-based reproducer works (i.e. does get
parallel (nested) write requests). I have no idea why we still get
parallel requests with qemu-img convert anyway.
Also, a later patch in this series will set fi->parallel_direct_writes
and note that it makes basically no difference when running fio on the
current libfuse-based version of our code. It does make a difference
without libfuse. So something quite fishy is going on.
I will try to investigate further what the root cause is, but I think
for now let's assume that calling blk_pwrite() can invalidate the buffer
contents through nested polling.
Cc: [email protected]
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Hanna Czenczek <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit a3fcbca0ef643a8aecf354bdeb08b1d81e5b33e7)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/2d3df8abca26...39b1f5e944f4
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
