Branch: refs/heads/stable-10.0
Home: https://github.com/qemu/qemu
Commit: c9afc732e22b0d7443f7774b7479c28c882c0b30
https://github.com/qemu/qemu/commit/c9afc732e22b0d7443f7774b7479c28c882c0b30
Author: Jamin Lin <[email protected]>
Date: 2025-05-29 (Thu, 29 May 2025)
Changed paths:
M hw/misc/aspeed_hace.c
Log Message:
-----------
hw/misc/aspeed_hace: Ensure HASH_IRQ is always set to prevent firmware hang
Currently, if the program encounters an unsupported algorithm, it does not set
the HASH_IRQ bit in the status register and send an interrupt to indicate
command completion. As a result, the FW gets stuck waiting for a completion
signal from the HACE module.
Additionally, in do_hash_operation, if an error occurs within the conditional
statement, the HASH_IRQ bit is not set in the status register. This causes the
firmware to continuously send HASH commands, as it is unaware that the HACE
model has completed processing the command.
To fix this, the HASH_IRQ bit in the status register must always be set to
ensure that the firmware receives an interrupt from the HACE module, preventing
it from getting stuck or repeatedly sending HASH commands.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: c5475b3 ("hw: Model ASPEED's Hash and Crypto Engine")
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 fb8e59abbe46957cd599bb9aa9221fad1e4e989e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 80a03b51b2a679e944c351eadbb391abc2f196e6
https://github.com/qemu/qemu/commit/80a03b51b2a679e944c351eadbb391abc2f196e6
Author: Jamin Lin <[email protected]>
Date: 2025-05-29 (Thu, 29 May 2025)
Changed paths:
M hw/arm/aspeed_ast27x0.c
Log Message:
-----------
hw/arm/aspeed_ast27x0: Fix RAM size detection failure on BE hosts
On big-endian hosts, the aspeed_ram_capacity_write() function previously passed
the address of a 64-bit "data" variable directly to address_space_write(),
assuming host and guest endianness matched.
However, the data is expected to be written in little-endian format to DRAM.
On big-endian hosts, this led to incorrect data being written into DRAM,
which caused the guest firmware to misdetect the DRAM size.
As a result, U-Boot fails to boot and hangs.
- Replaces the "address_space_write()" call with "address_space_stl_le()",
which performs an explicit 32-bit little-endian write.
- Updating the MemoryRegionOps to restrict access to exactly 4 bytes
using .valid.{min,max}_access_size = 4 and .impl.min_access_size = 4.
Signed-off-by: Jamin Lin <[email protected]>
Fixes: 7436db1 ("aspeed/soc: fix incorrect dram size for AST2700")
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 e6941ac106190490d8b455eedc5b368e6d94d4cc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6eea0cd5114ffc491a8bf73fd682676638f037e2
https://github.com/qemu/qemu/commit/6eea0cd5114ffc491a8bf73fd682676638f037e2
Author: Weifeng Liu <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/gtk.c
Log Message:
-----------
ui/gtk: Document scale and coordinate handling
The existence of multiple scaling factors forces us to deal with various
coordinate systems and this would be confusing. It would be beneficial
to define the concepts clearly and use consistent representation for
variables in different coordinates.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit 9498e2f7e1a247557cfa0f830a86c398a23c6809)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91fec603bdfb07b2339fd14c31abddb608974bb7
https://github.com/qemu/qemu/commit/91fec603bdfb07b2339fd14c31abddb608974bb7
Author: Weifeng Liu <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/gtk-egl.c
M ui/gtk-gl-area.c
M ui/gtk.c
Log Message:
-----------
ui/gtk: Use consistent naming for variables in different coordinates
Now that we've documented definitions and presentation of various
coordinates, let's enforce the rules.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit 3a6b314409b42fe7c46c2bd80cfc2a6744d414fe)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 43fecc5dde342ec9f04ee8a28d2b09f4cfe1450d
https://github.com/qemu/qemu/commit/43fecc5dde342ec9f04ee8a28d2b09f4cfe1450d
Author: Weifeng Liu <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M include/ui/gtk.h
M ui/gtk.c
Log Message:
-----------
gtk/ui: Introduce helper gd_update_scale
The code snippet updating scale_x/scale_y is general and will be used in
next patch. Make it a function.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit a19665448156f17b52b7f33e7960d57efcfca067)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a5a805068a2ca0dabf71f05c56bdbdba7360f985
https://github.com/qemu/qemu/commit/a5a805068a2ca0dabf71f05c56bdbdba7360f985
Author: Weifeng Liu <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/gtk-gl-area.c
Log Message:
-----------
ui/gtk: Update scales in fixed-scale mode when rendering GL area
When gl=on, scale_x and scale_y were set to 1 on startup that didn't
reflect the real situation of the scan-out in free scale mode, resulting
in incorrect cursor coordinates to be sent when moving the mouse
pointer. Simply updating the scales before rendering the image fixes
this issue.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit 8fb072472c38cb1778c5b0bebf535a8b13533857)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 613f05a4c653761550b1d5a5ff8993d1f8e22230
https://github.com/qemu/qemu/commit/613f05a4c653761550b1d5a5ff8993d1f8e22230
Author: Weifeng Liu <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/sdl2.c
Log Message:
-----------
ui/sdl: Consider scaling in mouse event handling
When using sdl display backend, if the window is scaled, incorrect mouse
positions will be reported since scaling is not properly handled. Fix it
by transforming the positions from window coordinate to guest buffer
coordinate.
Signed-off-by: Weifeng Liu <[email protected]>
Message-ID: <[email protected]>
Acked-by: Gerd Hoffmann <[email protected]>
Acked-by: Marc-André Lureau <[email protected]>
(cherry picked from commit 30aa105640b0a2a541744b6584d57c9a4b86debd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a610978bc55f0199344a5ba6bc6927f9fef08a11
https://github.com/qemu/qemu/commit/a610978bc55f0199344a5ba6bc6927f9fef08a11
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/vnc-enc-tight.c
M ui/vnc-enc-zrle.c
M ui/vnc-jobs.c
M ui/vnc.c
M ui/vnc.h
Log Message:
-----------
ui/vnc.c: replace big endian flag with byte order value
It will make it easier to do certain comparisons in future if we
store G_BIG_ENDIAN/G_LITTLE_ENDIAN directly, instead of a boolean
flag, as we can then compare directly to the G_BYTE_ORDER constant.
Reviewed-by: BALATON Zoltan <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 531cbd8e262d3e59059ea07a72d3aa71c9e94573
https://github.com/qemu/qemu/commit/531cbd8e262d3e59059ea07a72d3aa71c9e94573
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M include/ui/qemu-pixman.h
M ui/qemu-pixman.c
M ui/vnc-enc-tight.c
M ui/vnc.c
Log Message:
-----------
ui/vnc: take account of client byte order in pixman format
The set_pixel_conversion() method is responsible for determining whether
the VNC client pixel format matches the server format, and thus whether
we can use the fast path "copy" impl for sending pixels, or must use
the generic impl with bit swizzling.
The VNC server format is set at build time to VNC_SERVER_FB_FORMAT,
which corresponds to PIXMAN_x8r8g8b8.
The qemu_pixman_get_format() method is then responsible for converting
the VNC pixel format into a pixman format.
The VNC client pixel shifts are relative to the associated endianness.
The pixman formats are always relative to the host native endianness.
The qemu_pixman_get_format() method does not take into account the
VNC client endianness, and is thus returning a pixman format that is
only valid with the host endianness matches that of the VNC client.
This has been broken since pixman was introduced to the VNC server:
commit 9f64916da20eea67121d544698676295bbb105a7
Author: Gerd Hoffmann <[email protected]>
Date: Wed Oct 10 13:29:43 2012 +0200
pixman/vnc: use pixman images in vnc.
The flaw can be demonstrated using the Tigervnc client by using
vncviewer -AutoSelect=0 -PreferredEncoding=raw server:display
connecting from a LE client to a QEMU on a BE server, or the
reverse.
The bug was masked, however, because almost all VNC clients will
advertize support for the "tight" encoding and the QEMU VNC server
will prefer "tight" if advertized.
The tight_pack24 method is responsible for taking a set of pixels
which have already been converted into client endianness and then
repacking them into the TPIXEL format which the RFB spec defines
as
"TPIXEL is only 3 bytes long, where the first byte is the
red component, the second byte is the green component,
and the third byte is the blue component of the pixel
color value"
IOW, the TPIXEL format is fixed on the wire, regardless of what
the VNC client declare as its endianness.
Since the VNC pixel encoding code was failing to honour the endian
flag of the client, the tight_pack24 method was always operating
on data in native endianness. Its impl cancelled out the VNC pixel
encoding bug.
With the VNC pixel encoding code now fixed, the tight_pack24 method
needs to take into account that it is operating on data in client
endianness, not native endianness. It thus may need to invert the
pixel shifts.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 70097442853c389a765c9f6502d861d182b092ae)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9238fd846db22033cd12aca5736a25d69e1a5985
https://github.com/qemu/qemu/commit/9238fd846db22033cd12aca5736a25d69e1a5985
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-05-30 (Fri, 30 May 2025)
Changed paths:
M ui/vnc-enc-tight.c
Log Message:
-----------
ui/vnc: fix tight palette pixel encoding for 8/16-bpp formats
When sending a tight rectangle with the palette filter, if the client
format was 8/16bpp, the colours on big endian hosts are not set as
we're sending the wrong bytes. We must first cast the 32-bit colour
to a 16/8-bit value, and then send the result.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 63d320909220a90647c484263ae5e2f26eb54587)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1702044371d334bfe4e3ffd96378a419bae4f4f7
https://github.com/qemu/qemu/commit/1702044371d334bfe4e3ffd96378a419bae4f4f7
Author: Guenter Roeck <[email protected]>
Date: 2025-06-01 (Sun, 01 Jun 2025)
Changed paths:
M hw/arm/npcm8xx.c
Log Message:
-----------
hw/arm: Add missing psci_conduit to NPCM8XX SoC boot info
Without psci_conduit, the Linux kernel crashes almost immediately.
psci: probing for conduit method from DT.
Internal error: Oops - Undefined instruction: 0000000002000000 [#1] PREEMPT
SMP
Fixes: ae0c4d1a1290 ("hw/arm: Add NPCM8XX SoC")
Cc: [email protected]
Cc: Hao Wu <[email protected]>
Cc: Peter Maydell <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e6bc01777e5a4b6ecf3414b21a2d7b4846bf4817)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21f86e29510a7d8f6daca523ef4d630854c70b4f
https://github.com/qemu/qemu/commit/21f86e29510a7d8f6daca523ef4d630854c70b4f
Author: Huaitong Han <[email protected]>
Date: 2025-06-02 (Mon, 02 Jun 2025)
Changed paths:
M hw/pci/pci.c
M hw/virtio/virtio-pci.c
M include/hw/pci/pci.h
Log Message:
-----------
vhost: Don't set vring call if guest notifier is unused
The vring call fd is set even when the guest does not use MSI-X (e.g., in the
case of virtio PMD), leading to unnecessary CPU overhead for processing
interrupts.
The commit 96a3d98d2c("vhost: don't set vring call if no vector") optimized the
case where MSI-X is enabled but the queue vector is unset. However, there's an
additional case where the guest uses INTx and the INTx_DISABLED bit in the PCI
config is set, meaning that no interrupt notifier will actually be used.
In such cases, the vring call fd should also be cleared to avoid redundant
interrupt handling.
Fixes: 96a3d98d2c("vhost: don't set vring call if no vector")
Reported-by: Zhiyuan Yuan <[email protected]>
Signed-off-by: Jidong Xia <[email protected]>
Signed-off-by: Huaitong Han <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit a9403bfcd93025df7b1924d0cf34fbc408955b33)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 325d039d25f3626c0a52075e1d84e504f13e54c2
https://github.com/qemu/qemu/commit/325d039d25f3626c0a52075e1d84e504f13e54c2
Author: Bernhard Beschow <[email protected]>
Date: 2025-06-02 (Mon, 02 Jun 2025)
Changed paths:
M hw/i386/pc_piix.c
Log Message:
-----------
hw/i386/pc_piix: Fix RTC ISA IRQ wiring of isapc machine
Commit 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
attempted to refactor RTC IRQ wiring which was previously done in
pc_basic_device_init() but forgot about the isapc machine. Fix this by
wiring in the code section dedicated exclusively to the isapc machine.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2961
Fixes: 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 0b006153b7ec66505cb2d231235aa19ca5d2ce37)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8399ccb48041be54cec39b0c08494ea01ca84e4c
https://github.com/qemu/qemu/commit/8399ccb48041be54cec39b0c08494ea01ca84e4c
Author: Sairaj Kodilkar <[email protected]>
Date: 2025-06-02 (Mon, 02 Jun 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
hw/i386/amd_iommu: Fix device setup failure when PT is on.
Commit c1f46999ef506 ("amd_iommu: Add support for pass though mode")
introduces the support for "pt" flag by enabling nodma memory when
"pt=off". This allowed VFIO devices to successfully register notifiers
by using nodma region.
But, This also broke things when guest is booted with the iommu=nopt
because, devices bypass the IOMMU and use untranslated addresses (IOVA) to
perform DMA reads/writes to the nodma memory region, ultimately resulting in
a failure to setup the devices in the guest.
Fix the above issue by always enabling the amdvi_dev_as->iommu memory region.
But this will once again cause VFIO devices to fail while registering the
notifiers with AMD IOMMU memory region.
Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
(cherry picked from commit 31753d5a336fbb4e9246397f4b90b6f611f27f22)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c3e1181bafaecbcf9deae6a8bb4ad3586e221a3d
https://github.com/qemu/qemu/commit/c3e1181bafaecbcf9deae6a8bb4ad3586e221a3d
Author: Vasant Hegde <[email protected]>
Date: 2025-06-02 (Mon, 02 Jun 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
hw/i386/amd_iommu: Fix xtsup when vcpus < 255
If vCPUs > 255 then x86 common code (x86_cpus_init()) call kvm_enable_x2apic().
But if vCPUs <= 255 then the common code won't calls kvm_enable_x2apic().
This is because commit 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM
checks on XTSup feature") removed the call to kvm_enable_x2apic when xtsup
is "on", which break things when guest is booted with x2apic mode and
there are <= 255 vCPUs.
Fix this by adding back kvm_enable_x2apic() call when xtsup=on.
Fixes: 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM checks on XTSup
feature")
Reported-by: Alejandro Jimenez <[email protected]>
Tested-by: Tested-by: Alejandro Jimenez <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Cc: Joao Martins <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Signed-off-by: Sairaj Kodilkar <[email protected]>
Message-Id: <[email protected]>
Fixes: 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM checks on XTSup
feature")
Reported-by: Alejandro Jimenez <[email protected]>
Tested-by: Tested-by: Alejandro Jimenez <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Cc: Joao Martins <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Signed-off-by: Sairaj Kodilkar <[email protected]>
(cherry picked from commit 0f178860df3489a9d3c19a5f7f024e6aa6c26515)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 47ddae806b9272959965f05b72187bdc933c7d96
https://github.com/qemu/qemu/commit/47ddae806b9272959965f05b72187bdc933c7d96
Author: Volker Rümelin <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M audio/audio.c
Log Message:
-----------
audio: fix SIGSEGV in AUD_get_buffer_size_out()
As far as the emulated audio devices are concerned the pointer
returned by AUD_open_out() is an opaque handle. This includes
the NULL pointer. In this case, AUD_get_buffer_size_out() should
return a sensible buffer size instead of triggering a segmentation
fault. All other public AUD_*_out() and audio_*_out() functions
handle this case.
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 5ddd6c8dc849b4af44bd06840c9133d64e62c27c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6b12cb6edc09fa28429e72af12517e45b6c7c734
https://github.com/qemu/qemu/commit/6b12cb6edc09fa28429e72af12517e45b6c7c734
Author: Volker Rümelin <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M audio/audio.c
Log Message:
-----------
audio: fix size calculation in AUD_get_buffer_size_out()
The buffer size calculated by AUD_get_buffer_size_out() is often
incorrect. sw->hw->samples * sw->hw->info.bytes_per_frame is the
size of the mixing engine buffer in audio frames multiplied by
the size of one frame of the audio backend. Due to resampling or
format conversion, the size of the frontend buffer can differ
significantly.
Return the correct buffer size when the mixing engine is used.
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit ccb4fec0e5f233cb61a83b3af59ae11716ea06c0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 92d08b3c0d19467e2bb6ea079aba82c1e6ead9f5
https://github.com/qemu/qemu/commit/92d08b3c0d19467e2bb6ea079aba82c1e6ead9f5
Author: Volker Rümelin <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M hw/audio/asc.c
Log Message:
-----------
hw/audio/asc: fix SIGSEGV in asc_realize()
AUD_open_out() may fail and return NULL. This may then lead to
a segmentation fault in memset() below. The memset() behaviour
is undefined if the pointer to the destination object is a null
pointer.
Add the missing error handling code.
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d009f26a54f573468be721590a19350c224bc730)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9f80e4707cb05ab356c69ae8fde8537ef0b5810d
https://github.com/qemu/qemu/commit/9f80e4707cb05ab356c69ae8fde8537ef0b5810d
Author: Xin Li (Intel) <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: Remove FRED dependency on WRMSRNS
WRMSRNS doesn't become a required feature for FERD, and Linux has
removed the dependency, as such remove it from Qemu.
Cc: [email protected]
Signed-off-by: Xin Li (Intel) <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0b901459a87a7fdbed36e574aae33e0635a3e9af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d8e6f3f885cc9e72a7c298bd7fb830b6f48051cf
https://github.com/qemu/qemu/commit/d8e6f3f885cc9e72a7c298bd7fb830b6f48051cf
Author: Stefan Hajnoczi <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M tests/qemu-iotests/240
M tests/qemu-iotests/240.out
Log Message:
-----------
iotests: fix 240
Commit 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
removed the limitation that virtio-scsi devices must successfully set
the AioContext on their BlockBackends. This was made possible thanks to
the QEMU multi-queue block layer.
This change broke qemu-iotests 240, which checks that adding a
virtio-scsi device with a drive that is already in another AioContext
will fail.
Update the test to take the relaxed behavior into account. I considered
removing this test case entirely, but the code coverage still seems
valuable.
Fixes: 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Tested-by: Eric Blake <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 2e887187454e57d04522099d4f04d17137d6e05c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ab96ea4b4d257919f5d0042eedcb1c3cfa1d0a0c
https://github.com/qemu/qemu/commit/ab96ea4b4d257919f5d0042eedcb1c3cfa1d0a0c
Author: Fiona Ebner <[email protected]>
Date: 2025-06-05 (Thu, 05 Jun 2025)
Changed paths:
M hw/core/qdev-properties-system.c
Log Message:
-----------
hw/core/qdev-properties-system: Add missing return in set_drive_helper()
Currently, changing the 'drive' property of e.g. a scsi-hd object will
result in an assertion failure if the aio context of the block node
it's replaced with doesn't match the current aio context:
> bdrv_replace_child_noperm: Assertion `bdrv_get_aio_context(old_bs) ==
> bdrv_get_aio_context(new_bs)' failed.
The problematic scenario is already detected, but a 'return' statement
was missing.
Cc: [email protected]
Fixes: d1a58c176a ("qdev: allow setting drive property for realized device")
Signed-off-by: Fiona Ebner <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit eef2dd03f948a512499775043bdc0c5c88d8a2dd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6276ce6d702bd9a7390942bbc29acaaf03b53c4e
https://github.com/qemu/qemu/commit/6276ce6d702bd9a7390942bbc29acaaf03b53c4e
Author: Bibo Mao <[email protected]>
Date: 2025-06-12 (Thu, 12 Jun 2025)
Changed paths:
M hw/loongarch/virt-acpi-build.c
Log Message:
-----------
hw/loongarch/virt: Fix big endian support with MCFG table
With API build_mcfg(), it is not necessary with parameter structure
AcpiMcfgInfo to convert to little endian since it is directly used
with host native endian.
Here remove endian conversion before calling function build_mcfg().
With this patch, bios-tables-test passes to run on big endian host
machine S390.
Fixes: 735143f10d3e ("hw/loongarch: Add acpi ged support")
Cc: [email protected]
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Song Gao <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(cherry picked from commit 9c55c03c05c1899521ff0c991b9296633d759890)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c902fc66c9508c6fa2ec17510f5ae9241c0859fb
https://github.com/qemu/qemu/commit/c902fc66c9508c6fa2ec17510f5ae9241c0859fb
Author: Shameer Kolothum <[email protected]>
Date: 2025-06-17 (Tue, 17 Jun 2025)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm/virt: Check bypass iommu is not set for iommu-map DT property
default_bus_bypass_iommu tells us whether the bypass_iommu is set
for the default PCIe root bus. Make sure we check that before adding
the "iommu-map" DT property.
Cc: [email protected]
Fixes: 6d7a85483a06 ("hw/arm/virt: Add default_bus_bypass_iommu machine option")
Suggested-by: Eric Auger <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Donald Dutile <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit f5ec751ee70d7960a97c6c675f69e924d82dc60d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 436b3dd8cc8e8fe67d52716c51781fb0149dd0b2
https://github.com/qemu/qemu/commit/436b3dd8cc8e8fe67d52716c51781fb0149dd0b2
Author: Ethan Chen <[email protected]>
Date: 2025-06-17 (Tue, 17 Jun 2025)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options.hx: Fix reversed description of icount sleep behavior
The documentation for the -icount option incorrectly describes the behavior
of the sleep suboption. Based on the actual implementation and system
behavior, the effects of sleep=on and sleep=off were inadvertently reversed.
This commit updates the description to reflect their intended functionality.
Cc: [email protected]
Fixes: fa647905e6ba ("qemu-options.hx: Fix minor issues in icount
documentation")
Signed-off-by: Ethan Chen <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e372214e663a4370fe064f7867f402eade37357e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b7da1f5f5ddd196c7e992b6b7b746c5b54ae1d5a
https://github.com/qemu/qemu/commit/b7da1f5f5ddd196c7e992b6b7b746c5b54ae1d5a
Author: Peter Maydell <[email protected]>
Date: 2025-06-17 (Tue, 17 Jun 2025)
Changed paths:
M hw/arm/mps2.c
Log Message:
-----------
hw/arm/mps2: Configure the AN500 CPU with 16 MPU regions
The AN500 application note documents that it configures the Cortex-M7
CPU to have 16 MPU regions. We weren't doing this in our emulation,
so the CPU had only the default 8 MPU regions. Set the mpu-ns-regions
property to 16 for this board.
This bug doesn't affect any of the other board types we model in
this source file, because they all use either the Cortex-M3 or
Cortex-M4. Those CPUs do not have an RTL configurable number of
MPU regions, and always provide 8 regions if the MPU is built in.
Cc: [email protected]
Reported-by: Corentin GENDRE <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit cd38e638c43e4d5d3fd65dd4529c2e6153c9c408)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3cf25f4c71086ec96df7e3b0db7f093a684e6fda
https://github.com/qemu/qemu/commit/3cf25f4c71086ec96df7e3b0db7f093a684e6fda
Author: J. Neuschäfer <[email protected]>
Date: 2025-06-17 (Tue, 17 Jun 2025)
Changed paths:
M linux-user/arm/cpu_loop.c
Log Message:
-----------
linux-user/arm: Fix return value of SYS_cacheflush
Although the emulated cacheflush syscall does nothing, it still needs to
return zero to indicate success.
Cc: [email protected]
Signed-off-by: J. Neuschäfer <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 5ad2b1f443a96444cf3e7a2fbe17aae696201012)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fdd20285ae19cf26c0d8d561684fb8126fa48f22
https://github.com/qemu/qemu/commit/fdd20285ae19cf26c0d8d561684fb8126fa48f22
Author: Song Gao <[email protected]>
Date: 2025-06-17 (Tue, 17 Jun 2025)
Changed paths:
M target/loongarch/tcg/insn_trans/trans_fcmp.c.inc
M target/loongarch/tcg/insn_trans/trans_vec.c.inc
Log Message:
-----------
target/loongarch: add check for fcond
fcond only has 22 types, add a check for fcond.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2972
Signed-off-by: Song Gao <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit e7788da9860c97920c19fa1150806186513ef256)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 46cdfdfe9202c4e58aed99bfbf7e20f514c671cd
https://github.com/qemu/qemu/commit/46cdfdfe9202c4e58aed99bfbf7e20f514c671cd
Author: Song Gao <[email protected]>
Date: 2025-06-24 (Tue, 24 Jun 2025)
Changed paths:
M target/loongarch/tcg/insn_trans/trans_vec.c.inc
Log Message:
-----------
target/loongarch: fix vldi/xvldi raise wrong error
on qemu we got an aborted error
**
ERROR:../target/loongarch/tcg/insn_trans/trans_vec.c.inc:3574:vldi_get_value:
code should not be reached
Bail out!
ERROR:../target/loongarch/tcg/insn_trans/trans_vec.c.inc:3574:vldi_get_value:
code should not be reached
Aborted (core dumped)
but on 3A600/3A5000 we got a "Illegal instruction" error.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2971
Fixes: 29bb5d727ff ("target/loongarch: Implement vldi")
Cc: [email protected]
Reviewed-by: Bibo Mao <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Song Gao <[email protected]>
(cherry picked from commit c2a2e1ad2a749caa864281b1d4dc3f16c3f344f6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 22909a1397ad9679f0ffaba3016a3420ace2da21
https://github.com/qemu/qemu/commit/22909a1397ad9679f0ffaba3016a3420ace2da21
Author: Richard Henderson <[email protected]>
Date: 2025-07-01 (Tue, 01 Jul 2025)
Changed paths:
M tcg/tcg.c
Log Message:
-----------
tcg: Fix constant propagation in tcg_reg_alloc_dup
The scalar constant must be replicated for dup.
Cc: [email protected]
Fixes: bab1671f0fa ("tcg: Manually expand INDEX_op_dup_vec")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3002
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 0d0fc3f4658937fb81fcc16a89738e83bd8d4795)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ed4bad29e7dd437f7a8168dbe04b15909d945de9
https://github.com/qemu/qemu/commit/ed4bad29e7dd437f7a8168dbe04b15909d945de9
Author: Solomon Tan <[email protected]>
Date: 2025-07-02 (Wed, 02 Jul 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
target/arm: Make RETA[AB] UNDEF when pauth is not implemented
According to the Arm A-profile A64 Instruction Set Architecture,
RETA[AB] should be decoded as UNDEF if the pauth feature is not
implemented.
We got this right in the initial implementation, but accidentally
dropped the feature-check when we converted these insns to
decodetree.
Cc: [email protected]
Fixes: 0ebbe9021254f ("target/arm: Convert BRA[AB]Z, BLR[AB]Z, RETA[AB] to
decodetree")
Signed-off-by: Solomon Tan <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 9a3bf0e0ab628de7051b41a88c4628aa9e4d311b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5df7910a237ccb8ebd31f45d4216f3765c6010ed
https://github.com/qemu/qemu/commit/5df7910a237ccb8ebd31f45d4216f3765c6010ed
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-07-02 (Wed, 02 Jul 2025)
Changed paths:
M target/arm/hvf/hvf.c
M target/arm/kvm.c
Log Message:
-----------
target/arm: Correct KVM & HVF dtb_compatible value
Linux kernel knows how to parse "arm,armv8", not "arm,arm-v8".
See arch/arm64/boot/dts/foundation-v8.dts:
https://github.com/torvalds/linux/commit/90556ca1ebdd
Cc: [email protected]
Fixes: 26861c7ce06 ("target-arm: Add minimal KVM AArch64 support")
Fixes: 585df85efea ("hvf: arm: Implement -cpu host")
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit a412575837b6a46584fba891e3706e87bd09a3e6)
(Mjt: context fix in target/arm/kvm.c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fb9bad329cadba1f09642bb20a5ed2ce709b9dc3
https://github.com/qemu/qemu/commit/fb9bad329cadba1f09642bb20a5ed2ce709b9dc3
Author: Yiwei Zhang <[email protected]>
Date: 2025-07-03 (Thu, 03 Jul 2025)
Changed paths:
M hw/display/virtio-gpu-virgl.c
Log Message:
-----------
virtio-gpu: support context init multiple timeline
Venus and later native contexts have their own fence context along with
multiple timelines within. Fences wtih VIRTIO_GPU_FLAG_INFO_RING_IDX in
the flags must be dispatched to be created on the target context. Fence
signaling also has to be handled on the specific timeline within that
target context.
Before this change, venus fencing is completely broken if the host
driver doesn't support implicit fencing with external memory objects.
Frames can go backwards along with random artifacts on screen if the
host driver doesn't attach an implicit fence to the render target. The
symptom could be hidden by certain guest wsi backend that waits on a
venus native VkFence object for the actual payload with limited present
modes or under special configs. e.g. x11 mailbox or xwayland.
After this change, everything related to venus fencing starts making
sense. Confirmed this via guest and host side perfetto tracing.
Cc: [email protected]
Fixes: 94d0ea1c1928 ("virtio-gpu: Support Venus context")
Signed-off-by: Yiwei Zhang <[email protected]>
Reviewed-by: Dmitry Osipenko <[email protected]>
Message-Id: <[email protected]>
[AJB: remove version history from commit message]
Tested-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 1fa2ffdbec55d84326e22f046bc3e26322836f5a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b8f48f40334cb54df36e796b1e825a9061e0fbce
https://github.com/qemu/qemu/commit/b8f48f40334cb54df36e796b1e825a9061e0fbce
Author: Kevin Wolf <[email protected]>
Date: 2025-07-03 (Thu, 03 Jul 2025)
Changed paths:
M hw/s390x/ccw-device.c
Log Message:
-----------
hw/s390x/ccw-device: Fix memory leak in loadparm setter
Commit bdf12f2a fixed the setter for the "loadparm" machine property,
which gets a string from a visitor, passes it to s390_ipl_fmt_loadparm()
and then forgot to free it. It left another instance of the same problem
unfixed in the "loadparm" device property. Fix it.
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Reviewed-by: Halil Pasic <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 78e3781541209b3dcd6f4bb66adf3a3e504b88a4)
(Mjt: bdf12f2a is 8efe1592 in stable-10.0 branch)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 83b48a500f2f96f9403f7d255d9c58c623342542
https://github.com/qemu/qemu/commit/83b48a500f2f96f9403f7d255d9c58c623342542
Author: Richard Henderson <[email protected]>
Date: 2025-07-08 (Tue, 08 Jul 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
target/arm: Fix SME vs AdvSIMD exception priority
We failed to raise an exception when
sme_excp_el == 0 and fp_excp_el == 1.
Cc: [email protected]
Fixes: 3d74825f4d6 ("target/arm: Add SME enablement checks")
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit f9b0f69304071384b12912bf9dd78e9ffd261cec)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0e5f0d87f8e07d72688537282e19881cb9a323e6
https://github.com/qemu/qemu/commit/0e5f0d87f8e07d72688537282e19881cb9a323e6
Author: Richard Henderson <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
target/arm: Fix sve_access_check for SME
Do not assume SME implies SVE. Ensure that the non-streaming
check is present along the SME path, since it is not implied
by sme_*_enabled_check.
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit b4b2e070f41dd8774a70c6186141678558d79a38)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c76ec8d575fb8194a59908d25828286702390903
https://github.com/qemu/qemu/commit/c76ec8d575fb8194a59908d25828286702390903
Author: Richard Henderson <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M target/arm/tcg/translate-sve.c
Log Message:
-----------
target/arm: Fix 128-bit element ZIP, UZP, TRN
We missed the instructions UDEF when the vector size is too small.
We missed marking the instructions non-streaming with SME.
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e6ffd009c7710a8cc98094897fa0af609c114683)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9af1de0c4be21a37188af0a27b1b5c250004281c
https://github.com/qemu/qemu/commit/9af1de0c4be21a37188af0a27b1b5c250004281c
Author: Richard Henderson <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M target/arm/tcg/translate-sve.c
Log Message:
-----------
target/arm: Fix PSEL size operands to tcg_gen_gvec_ands
Gvec only operates on size 8 and multiples of 16.
Predicates may be any multiple of 2.
Round up the size using the appropriate function.
Cc: [email protected]
Fixes: 598ab0b24c0 ("target/arm: Implement PSEL")
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 3801c5b75ffc60957265513338e8fd5f8b6ce8a1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9a98db505f20d2e221ef086423483e028ed11937
https://github.com/qemu/qemu/commit/9a98db505f20d2e221ef086423483e028ed11937
Author: Richard Henderson <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M target/arm/tcg/sme_helper.c
Log Message:
-----------
target/arm: Fix f16_dotadd vs nan selection
Implement FPProcessNaNs4 within f16_dotadd, rather than
simply letting NaNs propagate through the function.
Cc: [email protected]
Fixes: 3916841ac75 ("target/arm: Implement FMOPA, FMOPS (widening)")
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit cfc688c00ade84f6b32c7814b52c217f1d3b5eb1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 005184da9d95f81ea6022e3f2e1dd95a881948be
https://github.com/qemu/qemu/commit/005184da9d95f81ea6022e3f2e1dd95a881948be
Author: Richard Henderson <[email protected]>
Date: 2025-07-09 (Wed, 09 Jul 2025)
Changed paths:
M target/arm/tcg/vec_helper.c
Log Message:
-----------
target/arm: Fix bfdotadd_ebf vs nan selection
Implement FPProcessNaNs4 within bfdotadd_ebf, rather than
simply letting NaNs propagate through the function.
Cc: [email protected]
Fixes: 0e1850182a1 ("target/arm: Implement FPCR.EBF=1 semantics for bfdotadd()")
Signed-off-by: Richard Henderson <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit bf020eaa6741711902a425016e2c7585f222562d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cae6ddfd7e6297d728ab6678d69e721fc38d345d
https://github.com/qemu/qemu/commit/cae6ddfd7e6297d728ab6678d69e721fc38d345d
Author: Mark Cave-Ayland <[email protected]>
Date: 2025-07-12 (Sat, 12 Jul 2025)
Changed paths:
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: fix TB exit logic in gen_movl_seg() when writing to SS
Before commit e54ef98c8a ("target/i386: do not trigger IRQ shadow for LSS"), any
write to SS in gen_movl_seg() would cause a TB exit. The changes introduced by
this commit were intended to restrict the DISAS_EOB_INHIBIT_IRQ exit to the case
where inhibit_irq is true, but missed that a DISAS_EOB_NEXT exit can still be
required when writing to SS and inhibit_irq is false.
Comparing the PE(s) && !VM86(s) section with the logic in x86_update_hflags(),
we
can see that the DISAS_EOB_NEXT exit is still required for the !CODE32 case when
writing to SS in gen_movl_seg() because any change to the SS flags can affect
hflags. Similarly we can see that the existing CODE32 case is still correct
since
a change to any of DS, ES and SS can affect hflags. Finally for the
gen_op_movl_seg_real() case an explicit TB exit is not needed because the
segment
register selector does not affect hflags.
Update the logic in gen_movl_seg() so that a write to SS with inhibit_irq set to
false where PE(s) && !VM86(s) will generate a DISAS_EOB_NEXT exit along with the
inline comment. This has the effect of allowing Win98SE to boot in QEMU once
again.
Signed-off-by: Mark Cave-Ayland <[email protected]>
Fixes: e54ef98c8a ("target/i386: do not trigger IRQ shadow for LSS")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2987
Link:
https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0f1d6606c28d0ae81a1b311972c5c54e5e867bf0)
Fixes: 0f1d6606c2 ("target/i386: do not trigger IRQ shadow for LSS" in 10.0.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fe000c4648b37782f4981fc386fec670304404a9
https://github.com/qemu/qemu/commit/fe000c4648b37782f4981fc386fec670304404a9
Author: Peter Maydell <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M target/arm/tcg/helper-a64.c
Log Message:
-----------
target/arm: Don't enforce NSE,NS check for EL3->EL3 returns
In the Arm ARM, rule R_TYTWB that defines illegal exception return cases
includes the case:
If FEAT_RME is implemented, then if SCR_EL3.{NSE, NS} is {1, 0}, an
exception return from EL3 to a lower Exception level
Our implementation of this check fails to check that the
return is to a lower exception level, so it will incorrectly fire on
EL3->EL3 exception returns.
Fix the check condition. This requires us to move it further
down in the function to a point where we know the new_el value.
Fixes: 35aa6715ddcd9 ("target/arm: Catch illegal-exception-return from EL3 with
bad NSE/NS")
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3016
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit c563cd7e61d074f58eef413322144461dd243716)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 676bc0f4a726627598e6f1d5979ee863191b54ba
https://github.com/qemu/qemu/commit/676bc0f4a726627598e6f1d5979ee863191b54ba
Author: Bernhard Beschow <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M hw/arm/fsl-imx8mp.c
Log Message:
-----------
hw/arm/fsl-imx8mp: Wire VIRQ and VFIQ
Allows to run KVM guests inside the imx8mp-evk machine.
Fixes: a4eefc69b237 ("hw/arm: Add i.MX 8M Plus EVK board")
CC: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 930180f3b9a292639eb894f1ca846683834ed4b7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1714828a56f150327cc05b242cabba4c3f891677
https://github.com/qemu/qemu/commit/1714828a56f150327cc05b242cabba4c3f891677
Author: Peter Maydell <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Implement fchmodat2 syscall
The fchmodat2 syscall is new from Linux 6.6; it is like the
existing fchmodat syscall except that it takes a flags parameter.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3019
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 6a3e132a1be8c9e649967a4eb341d00731be7f51)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1759558915c5052f560737061ca6333a16a924f5
https://github.com/qemu/qemu/commit/1759558915c5052f560737061ca6333a16a924f5
Author: Peter Maydell <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Check for EFAULT failure in nanosleep
target_to_host_timespec() returns an error if the memory the guest
passed us isn't actually readable. We check for this everywhere
except the callsite in the TARGET_NR_nanosleep case, so this mistake
was caught by a Coverity heuristic.
Add the missing error checks to the calls that convert between the
host and target timespec structs.
Coverity: CID 1507104
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit c4828cb8502d0b2adc39b9cde93df7d2886df897)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a4e31f5d8ec90a16a250fc39d807f79ce9d99760
https://github.com/qemu/qemu/commit/a4e31f5d8ec90a16a250fc39d807f79ce9d99760
Author: Geoffrey Thomas <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M linux-user/fd-trans.h
M linux-user/main.c
Log Message:
-----------
linux-user: Hold the fd-trans lock across fork
If another thread is holding target_fd_trans_lock during a fork,
then the lock becomes permanently locked in the child and the
emulator deadlocks at the next interaction with the fd-trans table.
As with other locks, acquire the lock in fork_start() and release
it in fork_end().
Cc: [email protected]
Signed-off-by: Geoffrey Thomas <[email protected]>
Fixes: c093364f4d91 "fd-trans: Fix race condition on reallocation of the
translation table."
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2846
Buglink: https://github.com/astral-sh/uv/issues/6105
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit e4e839b2eeea5745c48ce47144c7842eb7cd455f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b4ead907261c0a7228e43feb087c3b543da3620f
https://github.com/qemu/qemu/commit/b4ead907261c0a7228e43feb087c3b543da3620f
Author: Chaney, Ben <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration: Don't sync volatile memory after migration completes
Syncing volatile memory provides no benefit, instead it can cause
performance issues in some cases. Only sync memory that is marked as
non-volatile after migration completes on destination.
Signed-off-by: Ben Chaney <[email protected]>
Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 983899eab4939dc4dff67fa4d822c5b4df7eae21)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c49db93c360762587daf67a274a17749bc60ebe1
https://github.com/qemu/qemu/commit/c49db93c360762587daf67a274a17749bc60ebe1
Author: Peter Maydell <[email protected]>
Date: 2025-07-13 (Sun, 13 Jul 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Use qemu_set_cloexec() to mark pidfd as FD_CLOEXEC
In the linux-user do_fork() function we try to set the FD_CLOEXEC
flag on a pidfd like this:
fcntl(pid_fd, F_SETFD, fcntl(pid_fd, F_GETFL) | FD_CLOEXEC);
This has two problems:
(1) it doesn't check errors, which Coverity complains about
(2) we use F_GETFL when we mean F_GETFD
Deal with both of these problems by using qemu_set_cloexec() instead.
That function will assert() if the fcntls fail, which is fine (we are
inside fork_start()/fork_end() so we know nothing can mess around
with our file descriptors here, and we just got this one from
pidfd_open()).
(As we are touching the if() statement here, we correct the
indentation.)
Coverity: CID 1508111
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit d6390204c61e148488f034d1f79be35cd3318d93)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a655b6548fe2196031a3f325c5a4df7df65ff4cd
https://github.com/qemu/qemu/commit/a655b6548fe2196031a3f325c5a4df7df65ff4cd
Author: Thomas Huth <[email protected]>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
accel/kvm: Adjust the note about the minimum required kernel version
Since commit 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and
KVM_CAP_IOEVENTFD_ANY_LENGTH") we require at least kernel 4.5 to
be able to use KVM. Adjust the upgrade_note accordingly.
While we're at it, remove the text about kvm-kmod and the
SourceForge URL since this is not actively maintained anymore.
Fixes: 126e7f78036 ("kvm: require KVM_CAP_IOEVENTFD and
KVM_CAP_IOEVENTFD_ANY_LENGTH")
Signed-off-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit f180e367fce44b336105a11a62edf9610b6b2a06)
Commit: 6624ff39720c954081706822da15bc806ea4c318
https://github.com/qemu/qemu/commit/6624ff39720c954081706822da15bc806ea4c318
Author: Anastasia Belova <[email protected]>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M net/af-xdp.c
Log Message:
-----------
net: fix buffer overflow in af_xdp_umem_create()
s->pool has n_descs elements so maximum i should be
n_descs - 1. Fix the upper bound.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: cb039ef3d9 ("net: add initial support for AF_XDP network backend")
Cc: [email protected]
Reviewed-by: Ilya Maximets <[email protected]>
Signed-off-by: Anastasia Belova <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 110d0fa2d4d1f754242f6775baec43776a9adb35)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f272f318c02a4e41a91f1c87d677c44427a2ed89
https://github.com/qemu/qemu/commit/f272f318c02a4e41a91f1c87d677c44427a2ed89
Author: Akihiko Odaki <[email protected]>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M hw/net/virtio-net.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio-net: Add queues for RSS during migration
virtio_net_pre_load_queues() inspects vdev->guest_features to tell if
VIRTIO_NET_F_RSS or VIRTIO_NET_F_MQ is enabled to infer the required
number of queues. This works for VIRTIO_NET_F_MQ but it doesn't for
VIRTIO_NET_F_RSS because only the lowest 32 bits of vdev->guest_features
is set at the point and VIRTIO_NET_F_RSS uses bit 60 while
VIRTIO_NET_F_MQ uses bit 22.
Instead of inferring the required number of queues from
vdev->guest_features, use the number loaded from the vm state. This
change also has a nice side effect to remove a duplicate peer queue
pair change by circumventing virtio_net_set_multiqueue().
Also update the comment in include/hw/virtio/virtio.h to prevent an
implementation of pre_load_queues() from refering to any fields being
loaded during migration by accident in the future.
Fixes: 8c49756825da ("virtio-net: Add only one queue pair when realizing")
Tested-by: Lei Yang <[email protected]>
Cc: [email protected]
Signed-off-by: Akihiko Odaki <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit adda0ad56bd28d5a809051cbd190fda5798ec4e4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 10a9eedc2049ae977aadd77c973ef4f8522b01a2
https://github.com/qemu/qemu/commit/10a9eedc2049ae977aadd77c973ef4f8522b01a2
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Fix Miscellaneous Information Register 0 encoding
The definitions encoding the maximum Virtual, Physical, and Guest Virtual
Address sizes supported by the IOMMU are using incorrect offsets i.e. the
VASize and GVASize offsets are switched. The value in the GVAsize field is
also modified, since it was incorrectly encoded.
Cc: [email protected]
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Co-developed-by: Ethan MILON <[email protected]>
Signed-off-by: Ethan MILON <[email protected]>
Signed-off-by: Alejandro Jimenez <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 091c7d7924f33781c2fb8e7297dc54971e0c3785)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1ca9d2e0c2916174e50e6dd9fdce783ff1f33bdb
https://github.com/qemu/qemu/commit/1ca9d2e0c2916174e50e6dd9fdce783ff1f33bdb
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
amd_iommu: Fix Device ID decoding for INVALIDATE_IOTLB_PAGES command
The DeviceID bits are extracted using an incorrect offset in the call to
amdvi_iotlb_remove_page(). This field is read (correctly) earlier, so use
the value already retrieved for devid.
Cc: [email protected]
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit c63b8d1425ba8b3b08ee4f7346457fd8a7f12a24)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d1ea4a1b0effc5f6658688bc7a5c17a245b78fb5
https://github.com/qemu/qemu/commit/d1ea4a1b0effc5f6658688bc7a5c17a245b78fb5
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.c
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Update bitmasks representing DTE reserved fields
The DTE validation method verifies that all bits in reserved DTE fields are
unset. Update them according to the latest definition available in AMD I/O
Virtualization Technology (IOMMU) Specification - Section 2.2.2.1 Device
Table Entry Format. Remove the magic numbers and use a macro helper to
generate bitmasks covering the specified ranges for better legibility.
Note that some reserved fields specify that events are generated when they
contain non-zero bits, or checks are skipped under certain configurations.
This change only updates the reserved masks, checks for special conditions
are not yet implemented.
Cc: [email protected]
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit ff3dcb3bf652912466dcc1cd10d3267f185c212e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: caaa64850876a71c46ba0a3c9f5925e8cc49c600
https://github.com/qemu/qemu/commit/caaa64850876a71c46ba0a3c9f5925e8cc49c600
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Fix masks for various IOMMU MMIO Registers
Address various issues with definitions of the MMIO registers e.g. for the
Device Table Address Register, the size mask currently encompasses reserved
bits [11:9], so change it to only extract the bits [8:0] encoding size.
Convert masks to use GENMASK64 for consistency, and make unrelated
definitions independent.
Cc: [email protected]
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 108e10ff69099c3ebe147f505246be7c2ad2a499)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 18e70a46c3171feac4f80a6a3d4748a519160616
https://github.com/qemu/qemu/commit/18e70a46c3171feac4f80a6a3d4748a519160616
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Fix mask to retrieve Interrupt Table Root Pointer from DTE
Fix an off-by-one error in the definition of AMDVI_IR_PHYS_ADDR_MASK. The
current definition masks off the most significant bit of the Interrupt Table
Root ptr i.e. it only generates a mask with bits [50:6] set. See the AMD I/O
Virtualization Technology (IOMMU) Specification for the Interrupt Table
Root Pointer[51:6] field in the Device Table Entry format.
Cc: [email protected]
Fixes: b44159fe0078 ("x86_iommu/amd: Add interrupt remap support when VAPIC is
not enabled")
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 123cf4bdd378f746dfa2f5415ba084148dded3e3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 90c635c926c13187aa13575af489dd76de737341
https://github.com/qemu/qemu/commit/90c635c926c13187aa13575af489dd76de737341
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
amd_iommu: Fix the calculation for Device Table size
Correctly calculate the Device Table size using the format encoded in the
Device Table Base Address Register (MMIO Offset 0000h).
Cc: [email protected]
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 67d3077ee403472d45794399e97c9f329242fce9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fc1ad5124f5407437d0720fc51db6d88013add1a
https://github.com/qemu/qemu/commit/fc1ad5124f5407437d0720fc51db6d88013add1a
Author: Alejandro Jimenez <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Remove duplicated definitions
No functional change.
Signed-off-by: Alejandro Jimenez <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 5959b641c98b5ae9677e2c1d89902dac31b344d9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 787a817cd5691802d9ad69aa1bd969df615b47a9
https://github.com/qemu/qemu/commit/787a817cd5691802d9ad69aa1bd969df615b47a9
Author: Ethan Milon <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
amd_iommu: Fix truncation of oldval in amdvi_writeq
The variable `oldval` was incorrectly declared as a 32-bit `uint32_t`.
This could lead to truncation and incorrect behavior where the upper
read-only 32 bits are significant.
Fix the type of `oldval` to match the return type of `ldq_le_p()`.
Cc: [email protected]
Fixes: d29a09ca6842 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Ethan Milon <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 5788929e05e18ed5f76dc8ade4210f022c9ba5a1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e50ca171e2889ef2653bbf566caf9263ed3b970a
https://github.com/qemu/qemu/commit/e50ca171e2889ef2653bbf566caf9263ed3b970a
Author: Kevin Wolf <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M block/file-posix.c
Log Message:
-----------
file-posix: Fix aio=threads performance regression after enablign FUA
For aio=threads, we're currently not implementing REQ_FUA in any useful
way, but just do a separate raw_co_flush_to_disk() call. This changes
behaviour compared to the old state, which used bdrv_co_flush() with its
optimisations. As a quick fix, call bdrv_co_flush() again like before.
Eventually, we can use pwritev2() to make use of RWF_DSYNC if available,
but we'll still have to keep this code path as a fallback, so this fix
is required either way.
While the fix itself is a one-liner, some new graph locking annotations
are needed to convince TSA that the locking is correct.
Cc: [email protected]
Fixes: 984a32f17e8d ("file-posix: Support FUA writes")
Buglink: https://issues.redhat.com/browse/RHEL-96854
Reported-by: Tingting Mao <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit d402da1360c2240e81f0e5fc80ddbfc6238e0da8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2533500b4a0fa32737c90852103593f07fceeebf
https://github.com/qemu/qemu/commit/2533500b4a0fa32737c90852103593f07fceeebf
Author: Cole Robinson <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M pc-bios/hppa-firmware.img
M pc-bios/hppa-firmware64.img
Log Message:
-----------
roms: re-remove execute bit from hppa-firmware*
This was fixed in c9d77526bddba0803a1fa982fb59ec98057150f9 for
9.2.0 but regressed in db34be329162cf6b06192703065e6c1010dbe3c5 in
10.0.0
When the bit is present, rpmbuild complains about missing ELF build-id
Signed-off-by: Cole Robinson <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Acked-by: Helge Deller <[email protected]>
Message-ID:
<52d0edfbb9b2f63a866f0065a721f3a95da6f8ba.1747590860.git.crobi...@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit a598090ebaeb930ce33c2df0d80d87da13be8848)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 12e88c0c6c9448ab383258f1e477c211cf407350
https://github.com/qemu/qemu/commit/12e88c0c6c9448ab383258f1e477c211cf407350
Author: David Hildenbrand <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M hw/virtio/vhost.c
Log Message:
-----------
vhost: Fix used memslot tracking when destroying a vhost device
When we unplug a vhost device, we end up calling vhost_dev_cleanup()
where we do a memory_listener_unregister().
This memory_listener_unregister() call will end up disconnecting the
listener from the address space through listener_del_address_space().
In that process, we effectively communicate the removal of all memory
regions from that listener, resulting in region_del() + commit()
callbacks getting triggered.
So in case of vhost, we end up calling vhost_commit() with no remaining
memory slots (0).
In vhost_commit() we end up overwriting the global variables
used_memslots / used_shared_memslots, used for detecting the number
of free memslots. With used_memslots / used_shared_memslots set to 0
by vhost_commit() during device removal, we'll later assume that the
other vhost devices still have plenty of memslots left when calling
vhost_get_free_memslots().
Let's fix it by simply removing the global variables and depending
only on the actual per-device count.
Easy to reproduce by adding two vhost-user devices to a VM and then
hot-unplugging one of them.
While at it, detect unexpected underflows in vhost_get_free_memslots()
and issue a warning.
Reported-by: yuanminghao <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]/
Fixes: 2ce68e4cf5be ("vhost: add vhost_has_free_slot() interface")
Cc: Igor Mammedov <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Cc: Stefano Garzarella <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Igor Mammedov <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 9f749129e2629b19f424df106c92c5a5647e396c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2df7954daa523748e1067713d52a6baa334d3dc6
https://github.com/qemu/qemu/commit/2df7954daa523748e1067713d52a6baa334d3dc6
Author: Akihiko Odaki <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M ui/vnc-enc-zlib.c
M ui/vnc.c
M ui/vnc.h
Log Message:
-----------
ui/vnc: Do not copy z_stream
vnc_worker_thread_loop() copies z_stream stored in its local VncState to
the persistent VncState, and the copied one is freed with deflateEnd()
later. However, deflateEnd() refuses to operate with a copied z_stream
and returns Z_STREAM_ERROR, leaking the allocated memory.
Avoid copying the zlib state to fix the memory leak.
Fixes: bd023f953e5e ("vnc: threaded VNC server")
Signed-off-by: Akihiko Odaki <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit aef22331b5a4670f42638a5f63a26e93bf779aae)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d0975531586742ec2eff8796b7ba93bc4858e63d
https://github.com/qemu/qemu/commit/d0975531586742ec2eff8796b7ba93bc4858e63d
Author: Michael Tokarev <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/cpu: Fix cpu number overflow in CPUID.01H.EBX[23:16]
The legacy topology enumerated by CPUID.1.EBX[23:16] is defined in SDM
Vol2:
Bits 23-16: Maximum number of addressable IDs for logical processors in
this physical package.
When threads_per_socket > 255, it will 1) overwrite bits[31:24] which is
apic_id, 2) bits [23:16] get truncated.
Specifically, if launching the VM with -smp 256, the value written to
EBX[23:16] is 0 because of data overflow. If the guest only supports
legacy topology, without V2 Extended Topology enumerated by CPUID.0x1f
or Extended Topology enumerated by CPUID.0x0b to support over 255 CPUs,
the return of the kernel invoking cpu_smt_allowed() is false and APs
(application processors) will fail to bring up. Then only CPU 0 is online,
and others are offline.
For example, launch VM via:
qemu-system-x86_64 -M q35,accel=kvm,kernel-irqchip=split \
-cpu qemu64,cpuid-0xb=off -smp 256 -m 32G \
-drive file=guest.img,if=none,id=virtio-disk0,format=raw \
-device virtio-blk-pci,drive=virtio-disk0,bootindex=1 --nographic
The guest shows:
CPU(s): 256
On-line CPU(s) list: 0
Off-line CPU(s) list: 1-255
To avoid this issue caused by overflow, limit the max value written to
EBX[23:16] to 255 as the HW does.
Cc: [email protected]
Reviewed-by: Xiaoyao Li <[email protected]>
Signed-off-by: Qian Wen <[email protected]>
Signed-off-by: Zhao Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit a62fef58299562aae6667b8d8552247423e886b3)
(Mjt: fixup for 10.0.x series due to missing v10.0.0-2217-gf985a1195b
"i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 18224789994e0276a626a4e4e5554695857bd998
https://github.com/qemu/qemu/commit/18224789994e0276a626a4e4e5554695857bd998
Author: Qian Wen <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/cpu: Fix overflow of cache topology fields in CPUID.04H
According to SDM, CPUID.0x4:EAX[31:26] indicates the Maximum number of
addressable IDs for processor cores in the physical package. If we
launch over 64 cores VM, the 6-bit field will overflow, and the wrong
core_id number will be reported.
Since the HW reports 0x3f when the intel processor has over 64 cores,
limit the max value written to EAX[31:26] to 63, so max num_cores should
be 64.
For EAX[14:25], though at present Q35 supports up to 4096 CPUs, by
constructing a specific topology, the width of the APIC ID can be
extended beyond 12 bits. For example, using `-smp threads=33,cores=9,
modules=9` results in a die level offset of 6 + 4 + 4 = 14 bits, which
can also cause overflow. check and honor the maximum value for
EAX[14:25] as well.
In addition, for host-cache-info case, also apply the same checks and
fixes.
Reviewed-by: Xiaoyao Li <[email protected]>
Signed-off-by: Qian Wen <[email protected]>
Signed-off-by: Zhao Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3e86124e7cb9b66e07fb992667865a308f16fcf2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82517381c54d87985994ad597d274e3f2e18a484
https://github.com/qemu/qemu/commit/82517381c54d87985994ad597d274e3f2e18a484
Author: Zhao Liu <[email protected]>
Date: 2025-07-17 (Thu, 17 Jul 2025)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386/cpu: Honor maximum value for CPUID.8000001DH.EAX[25:14]
CPUID.8000001DH:EAX[25:14] is "NumSharingCache", and the number of
logical processors sharing this cache is the value of this field
incremented by 1. Because of its width limitation, the maximum value
currently supported is 4095.
Though at present Q35 supports up to 4096 CPUs, by constructing a
specific topology, the width of the APIC ID can be extended beyond 12
bits. For example, using `-smp threads=33,cores=9,modules=9` results in
a die level offset of 6 + 4 + 4 = 14 bits, which can also cause
overflow. Check and honor the maximum value as CPUID.04H did.
Cc: Babu Moger <[email protected]>
Signed-off-by: Zhao Liu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5d21ee453ad8e3f95f75e542cb3b35c5bb7cf23a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 24778b1c7ee7aca9721ed4757b0e0df0c16390f7
https://github.com/qemu/qemu/commit/24778b1c7ee7aca9721ed4757b0e0df0c16390f7
Author: Paolo Bonzini <[email protected]>
Date: 2025-07-19 (Sat, 19 Jul 2025)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
target/i386: do not expose ARCH_CAPABILITIES on AMD CPU
KVM emulates the ARCH_CAPABILITIES on x86 for both Intel and AMD
cpus, although the IA32_ARCH_CAPABILITIES MSR is an Intel-specific
MSR and it makes no sense to emulate it on AMD.
As a consequence, VMs created on AMD with qemu -cpu host and using
KVM will advertise the ARCH_CAPABILITIES feature and provide the
IA32_ARCH_CAPABILITIES MSR. This can cause issues (like Windows BSOD)
as the guest OS might not expect this MSR to exist on such cpus (the
AMD documentation specifies that ARCH_CAPABILITIES feature and MSR
are not defined on the AMD architecture).
A fix was proposed in KVM code, however KVM maintainers don't want to
change this behavior that exists for 6+ years and suggest changes to be
done in QEMU instead. Therefore, hide the bit from "-cpu host":
migration of -cpu host guests is only possible between identical host
kernel and QEMU versions, therefore this is not a problematic breakage.
If a future AMD machine does include the MSR, that would re-expose the
Windows guest bug; but it would not be KVM/QEMU's problem at that
point, as we'd be following a genuine physical CPU impl.
Reported-by: Alexandre Chartre <[email protected]>
Suggested-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit d3a24134e37d57abd3e7445842cda2717f49e96d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9561a8c14049a851bb5b83d92707bec2d6692052
https://github.com/qemu/qemu/commit/9561a8c14049a851bb5b83d92707bec2d6692052
Author: Peter Maydell <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M hw/net/npcm_gmac.c
Log Message:
-----------
hw/net/npcm_gmac.c: Send the right data for second packet in a row
The transmit loop in gmac_try_send_next_packet() is constructed in a
way that means it will send incorrect data if it it sends more than
one packet.
The function assembles the outbound data in a dynamically allocated
block of memory which is pointed to by tx_send_buffer. We track the
first point in this block of memory which is not yet used with the
prev_buf_size offset, initially zero. We track the size of the
packet we're sending with the length variable, also initially zero.
As we read chunks of data out of guest memory, we write them to
tx_send_buffer[prev_buf_size], and then increment both prev_buf_size
and length. (We might dynamically reallocate the buffer if needed.)
When we send a packet, we checksum and send length bytes, starting at
tx_send_buffer, and then we reset length to 0. This gives the right
data for the first packet. But we don't reset prev_buf_size. This
means that if we process more descriptors with further data for the
next packet, that data will continue to accumulate at offset
prev_buf_size, i.e. after the data for the first packet. But when
we transmit that second packet, we send length bytes from
tx_send_buffer, so we will send a packet which has the length of the
second packet but the data of the first one.
The fix for this is to also clear prev_buf_size after the packet has
been sent -- we never need the data from packet one after we've sent
it, so we can write packet two's data starting at the beginning of
the buffer.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 871a6e5b339f0b5e71925ec7d3f452944a1c82d3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 08fa61a3652e36e6966bc6a3473f7a333c4058a5
https://github.com/qemu/qemu/commit/08fa61a3652e36e6966bc6a3473f7a333c4058a5
Author: Daniel P. Berrangé <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui: fix setting client_endian field defaults
When a VNC client sends a "set pixel format" message, the
'client_endian' field will get initialized, however, it is
valid to omit this message if the client wants to use the
server's native pixel format. In the latter scenario nothing
is initializing the 'client_endian' field, so it remains set
to 0, matching neither G_LITTLE_ENDIAN nor G_BIG_ENDIAN. This
then results in pixel format conversion routines taking the
wrong code paths.
This problem existed before the 'client_be' flag was changed
into the 'client_endian' value, but the lack of initialization
meant it semantically defaulted to little endian, so only big
endian systems would potentially be exposed to incorrect pixel
translation.
The 'virt-viewer' / 'remote-viewer' apps always send a "set
pixel format" message so aren't exposed to any problems, but
the classical 'vncviewer' app will show the problem easily.
Fixes: 7ed96710e82c385c6cfc3d064eec7dde20f0f3fd
Reported-by: Thomas Huth <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Daniel P. Berrangé <[email protected]>
(cherry picked from commit 3ac6daa9e1c5d7dae2a3cd1c6a388174b462f3e8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3341f5cd5c391c6b460f2f70cc694ca5ef3b2191
https://github.com/qemu/qemu/commit/3341f5cd5c391c6b460f2f70cc694ca5ef3b2191
Author: Peter Maydell <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M target/arm/debug_helper.c
Log Message:
-----------
target/arm: Correct encoding of Debug Communications Channel registers
We don't implement the Debug Communications Channel (DCC), but
we do attempt to provide dummy versions of its system registers
so that software that tries to access them doesn't fall over.
However, we got the tx/rx register definitions wrong. These
should be:
AArch32:
DBGDTRTX p14 0 c0 c5 0 (on writes)
DBGDTRRX p14 0 c0 c5 0 (on reads)
AArch64:
DBGDTRTX_EL0 2 3 0 5 0 (on writes)
DBGDTRRX_EL0 2 3 0 5 0 (on reads)
DBGDTR_EL0 2 3 0 4 0 (reads and writes)
where DBGDTRTX and DBGDTRRX are effectively different names for the
same 32-bit register, which has tx behaviour on writes and rx
behaviour on reads. The AArch64-only DBGDTR_EL0 is a 64-bit wide
register whose top and bottom halves map to the DBGDTRRX and DBGDTRTX
registers.
Currently we have just one cpreg struct, which:
* calls itself DBGDTR_EL0
* uses the DBGDTRTX_EL0/DBGDTRRX_EL0 encoding
* is marked as ARM_CP_STATE_BOTH but has the wrong opc1
value for AArch32
* is implemented as RAZ/WI
Correct the encoding so:
* we name the DBGDTRTX/DBGDTRRX register correctly
* we split it into AA64 and AA32 versions so we can get the
AA32 encoding right
* we implement DBGDTR_EL0 at its correct encoding
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2986
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 655659a74a36b63e33d2dc969d3c44beb1b008b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a5ac9803d513586eefe6c7613b3c3bcc1b9e5943
https://github.com/qemu/qemu/commit/a5ac9803d513586eefe6c7613b3c3bcc1b9e5943
Author: Zenghui Yu <[email protected]>
Date: 2025-07-21 (Mon, 21 Jul 2025)
Changed paths:
M target/arm/hvf/hvf.c
Log Message:
-----------
hvf: arm: Emulate ICC_RPR_EL1 accesses properly
Commit a2260983c655 ("hvf: arm: Add support for GICv3") added GICv3 support
by implementing emulation for a few system registers. ICC_RPR_EL1 was
defined but not plugged in the sysreg handlers (for no good reason).
Fix it.
Fixes: a2260983c655 ("hvf: arm: Add support for GICv3")
Signed-off-by: Zenghui Yu <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e6da704b711d5d731e4d933ad56cbbc25ee0a825)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 66d21643c2b8f2bec969a80ccea09667c77151ee
https://github.com/qemu/qemu/commit/66d21643c2b8f2bec969a80ccea09667c77151ee
Author: Michael Tokarev <[email protected]>
Date: 2025-07-22 (Tue, 22 Jul 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 10.0.3 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/ff3419cbacdc...66d21643c2b8
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
