Branch: refs/heads/stable-7.2
Home: https://github.com/qemu/qemu
Commit: 0f6b895992d00ec9794e72f9106d963033edc8f6
https://github.com/qemu/qemu/commit/0f6b895992d00ec9794e72f9106d963033edc8f6
Author: Khem Raj <[email protected]>
Date: 2025-02-11 (Tue, 11 Feb 2025)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Do not define struct sched_attr if libc headers do
glibc 2.41+ has added [1] definitions for sched_setattr and
sched_getattr functions and struct sched_attr. Therefore, it needs
to be checked for here as well before defining sched_attr, to avoid
a compilation failure.
Define sched_attr conditionally only when SCHED_ATTR_SIZE_VER0 is
not defined.
[1]
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=21571ca0d70302909cf72707b2a7736cf12190a0;hp=298bc488fdc047da37482f4003023cb9adef78f8
Signed-off-by: Khem Raj <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2799
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 27a8d899c7a100fd5aa040a8b993bb257687c393)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9d820b19b14d8cbef88763ee54ced8325431ba56
https://github.com/qemu/qemu/commit/9d820b19b14d8cbef88763ee54ced8325431ba56
Author: Volker Rümelin <[email protected]>
Date: 2025-02-16 (Sun, 16 Feb 2025)
Changed paths:
M ui/meson.build
M ui/sdl2.c
Log Message:
-----------
ui/sdl2: reenable the SDL2 Windows keyboard hook procedure
Windows only:
The libSDL2 Windows message loop needs the libSDL2 Windows low
level keyboard hook procedure to grab the left and right Windows
keys correctly. Reenable the SDL2 Windows keyboard hook procedure.
Since SDL2 2.30.4 the SDL2 keyboard hook procedure also filters
out the special left Control key event for every Alt Gr key event
on keyboards with an international layout. This means the QEMU low
level keyboard hook procedure is no longer needed. Remove the QEMU
Windows keyboard hook procedure.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2139
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2323
Signed-off-by: Volker Rümelin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 4dafba778aa3e5f5fd3b2c6333afd7650dcf54e2)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: context fix in ui/sdl2.c and adaptation in ui/meson.build)
Commit: 3085db5cad11cb91c3055e490fcea2fc16d7cad2
https://github.com/qemu/qemu/commit/3085db5cad11cb91c3055e490fcea2fc16d7cad2
Author: Mikael Szreder <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/sparc/gdbstub.c
Log Message:
-----------
target/sparc: Fix gdbstub incorrectly handling registers f32-f62
The gdbstub implementation for the Sparc architecture would
incorrectly calculate the the floating point register offset.
This resulted in, for example, registers f32 and f34 to point to
the same value.
The issue was caused by the confusion between even register numbers
and even register indexes. For example, the register index of f32 is 64
and f34 is 65.
Cc: [email protected]
Fixes: 30038fd81808 ("target-sparc: Change fpr representation to doubles.")
Signed-off-by: Mikael Szreder <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 7a74e468089a58756b438d31a2a9a97f183780d7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 74726f912980c13fcc9a708ea2786d6e5b25a7d1
https://github.com/qemu/qemu/commit/74726f912980c13fcc9a708ea2786d6e5b25a7d1
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED CNTPS_*_EL1 from EL2 and NS
EL1
The access pseudocode for the CNTPS_TVAL_EL1, CNTPS_CTL_EL1 and
CNTPS_CVAL_EL1 secure timer registers says that they are UNDEFINED
from EL2 or NS EL1. We incorrectly return CP_ACCESS_TRAP from the
access function in these cases, which means that we report the wrong
syndrome value to the target EL.
Use CP_ACCESS_TRAP_UNCATEGORIZED, which reports the correct syndrome
value for an UNDEFINED instruction.
Cc: [email protected]
Fixes: b4d3978c2fd ("target-arm: Add the AArch64 view of the Secure physical
timer")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit b819fd6994243aee6f9613edbbacedce4f511c32)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d4b92c191485be23c070f65e79cc86c82827e743
https://github.com/qemu/qemu/commit/d4b92c191485be23c070f65e79cc86c82827e743
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED S1E2 AT ops at EL3
The pseudocode for AT S1E2R and AT S1E2W says that they should be
UNDEFINED if executed at EL3 when EL2 is not enabled. We were
incorrectly using CP_ACCESS_TRAP and reporting the wrong exception
syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: [email protected]
Fixes: 2a47df953202e1 ("target-arm: Wire up AArch64 EL2 and EL3 address
translation ops")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit ccda792945d650bce4609c8dbce8814a220df1bb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 83e270868b6ee1816aa4fda17fd1cb7b638acc7b
https://github.com/qemu/qemu/commit/83e270868b6ee1816aa4fda17fd1cb7b638acc7b
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Report correct syndrome for UNDEFINED LOR sysregs when NS=0
The pseudocode for the accessors for the LOR sysregs says they
are UNDEFINED if SCR_EL3.NS is 0. We were reporting the wrong
syndrome value here; use CP_ACCESS_TRAP_UNCATEGORIZED.
Cc: [email protected]
Fixes: 2d7137c10faf ("target/arm: Implement the ARMv8.1-LOR extension")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 707d478ed8f2da6f2327e5af780890c1fd9c371a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8fd043112a2fc867b31f261e8c943fe3e6c20892
https://github.com/qemu/qemu/commit/8fd043112a2fc867b31f261e8c943fe3e6c20892
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/op_helper.c
Log Message:
-----------
target/arm: Make CP_ACCESS_TRAPs to AArch32 EL3 be Monitor traps
In system register access pseudocode the common pattern for
AArch32 registers with access traps to EL3 is:
at EL1 and EL2:
if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then
AArch64.AArch32SystemAccessTrap(EL3, 0x03);
elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
at EL3:
if (PSTATE.M != M32_Monitor) && (SCR.TERR == 1) then
AArch32.TakeMonitorTrapException();
(taking as an example the ERRIDR access pseudocode).
This implements the behaviour of (in this case) SCR.TERR that
"Accesses to the specified registers from modes other than Monitor
mode generate a Monitor Trap exception" and of SCR_EL3.TERR that
"Accesses of the specified Error Record registers at EL2 and EL1
are trapped to EL3, unless the instruction generates a higher
priority exception".
In QEMU we don't implement this pattern correctly in two ways:
* in access_check_cp_reg() we turn the CP_ACCESS_TRAP_EL3 into
an UNDEF, not a trap to Monitor mode
* in the access functions, we check trap bits like SCR.TERR
only when arm_current_el(env) < 3 -- this is correct for
AArch64 EL3, but misses the "trap non-Monitor-mode execution
at EL3 into Monitor mode" case for AArch32 EL3
In this commit we fix the first of these two issues, by
making access_check_cp_reg() handle CP_ACCESS_TRAP_EL3
as a Monitor trap. This is a kind of exception that we haven't
yet implemented(!), so we need a new EXCP_MON_TRAP for it.
This diverges from the pseudocode approach, where every access check
function explicitly checks for "if EL3 is AArch32" and takes a
monitor trap; if we wanted to be closer to the pseudocode we could
add a new CP_ACCESS_TRAP_MONITOR and make all the accessfns use it
when appropriate. But because there are no non-standard cases in the
pseudocode (i.e. where either it raises a Monitor trap that doesn't
correspond to an AArch64 SystemAccessTrap or where it raises a
SystemAccessTrap that doesn't correspond to a Monitor trap), handling
this all in one place seems less likely to result in future bugs
where we forgot again about this special case when writing an
accessor.
(The cc of stable here is because "hw/intc/arm_gicv3_cpuif: Don't
downgrade monitor traps for AArch32 EL3" which is also cc:stable
will implicitly use the new EXCP_MON_TRAP code path.)
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4cf4948651615181c5bc3d0e4a9f5c46be576bb2)
(Mjt: context fix due to missing
v9.0.0-151-gb36a32ead159 "target/arm: Add support for Non-maskable Interrupt",
v8.0.0-2011-g11b76fda0adc "target/arm: Implement GPC exceptions")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a7e5c52e72c330dee53dee13e7647ffff7b98d8b
https://github.com/qemu/qemu/commit/a7e5c52e72c330dee53dee13e7647ffff7b98d8b
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
Log Message:
-----------
hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3
In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check
which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not
AArch64. This has been there since the GIC was first implemented,
but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ
then we definitely want to be going to EL3 (doing
AArch32.TakeMonitorTrapException() in pseudocode terms). We might
want to not take a trap at all, but we don't ever want to go to the
default target EL, because that would mean, for instance, taking a
trap to Hyp mode if the trapped access was made from Hyp mode.
(This might have been an attempt to work around our failure to
properly implement Monitor Traps.)
Remove the bogus check.
Cc: [email protected]
Fixes: 359fbe65e01e ("hw/intc/arm_gicv3: Implement GICv3 CPU interface
registers")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit d04c6c3c000ab3e588a2b91641310aeea89408f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8b7ff3d4b79759aa80dd28b93e4ddac5aa093ffc
https://github.com/qemu/qemu/commit/8b7ff3d4b79759aa80dd28b93e4ddac5aa093ffc
Author: Bernhard Beschow <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/arm/Kconfig
M hw/usb/Kconfig
M hw/usb/meson.build
Log Message:
-----------
Kconfig: Extract CONFIG_USB_CHIPIDEA from CONFIG_IMX
TYPE_CHIPIDEA models an IP block which is also used in TYPE_ZYNQ_MACHINE which
itself is not an IMX device. CONFIG_ZYNQ selects CONFIG_USB_EHCI_SYSBUS while
TYPE_CHIPIDEA is a separate compilation unit, so only works by accident if
CONFIG_IMX is given. Fix that by extracting CONFIG_USB_CHIPIDEA from CONFIG_IMX.
cc: [email protected]
Fixes: 616ec12d0fcc "hw/arm/xilinx_zynq: Fix USB port instantiation"
Signed-off-by: Bernhard Beschow <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 464ce71a963b3dfc290cd59c3d1bfedf11c004df)
(Mjt: context fixup due to missing
v8.0.0-1939-gde6cd7599b51 "meson: Replace softmmu_ss -> system_ss",
v9.1.0-609-ge02491903d50 "hw/usb: Remove tusb6010 USB controller",
v9.2.0-1303-g1b326f278d05 "hw/pci-host/designware: Expose MSI IRQ")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 307224ae499aa33cb60af470ff387ea8402ed2a7
https://github.com/qemu/qemu/commit/307224ae499aa33cb60af470ff387ea8402ed2a7
Author: Sairaj Kodilkar <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
amd_iommu: Use correct DTE field for interrupt passthrough
Interrupt passthrough is determine by the bits 191,190,187-184.
These bits are part of the 3rd quad word (i.e. index 2) in DTE. Hence
replace dte[3] by dte[2].
Fixes: b44159fe0 ("x86_iommu/amd: Add interrupt remap support when VAPIC is not
enabled")
Signed-off-by: Sairaj Kodilkar <[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 63dc0b8647391b372f3bb38ff1066f6b4a5e6ea1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e5cb461073122c965f06860fb2a3e5f57f66dc20
https://github.com/qemu/qemu/commit/e5cb461073122c965f06860fb2a3e5f57f66dc20
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
hw/i386/amd_iommu: Explicit use of AMDVI_BASE_ADDR in amdvi_init
By accessing MemoryRegion internals, amdvi_init() gives the false
idea that the PCI BAR can be modified. However this isn't true
(at least the model isn't ready for that): the device is explicitly
maps at the BAR at the fixed AMDVI_BASE_ADDR address in
amdvi_sysbus_realize(). Since the SysBus API isn't designed to
remap regions, directly use the fixed address in amdvi_init().
Signed-off-by: Philippe Mathieu-Daudé <[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 6291a28645a0656477bc5962a81b181e6a99487c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d34cd1f2dcb751bac6f1085d0b4c97e2d1a42355
https://github.com/qemu/qemu/commit/d34cd1f2dcb751bac6f1085d0b4c97e2d1a42355
Author: Sairaj Kodilkar <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/i386/amd_iommu.c
M hw/i386/amd_iommu.h
Log Message:
-----------
amd_iommu: Use correct bitmask to set capability BAR
AMD IOMMU provides the base address of control registers through
IVRS table and PCI capability. Since this base address is of 64 bit,
use 32 bits mask (instead of 16 bits) to set BAR low and high.
Fixes: d29a09ca68 ("hw/i386: Introduce AMD IOMMU")
Signed-off-by: Sairaj Kodilkar <[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 3684717b7407cc395dc9bf522e193dbc85293dee)
(Mjt: adjust for 7.2.x)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3e59a2255d10d21e1900c6e2c10fbb2f99df96f6
https://github.com/qemu/qemu/commit/3e59a2255d10d21e1900c6e2c10fbb2f99df96f6
Author: Stefano Garzarella <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M backends/cryptodev-vhost.c
Log Message:
-----------
cryptodev/vhost: allocate CryptoDevBackendVhost using g_mem0()
The function `vhost_dev_init()` expects the `struct vhost_dev`
(passed as a parameter) to be fully initialized. This is important
because some parts of the code check whether `vhost_dev->config_ops`
is NULL to determine if it has been set (e.g. later via
`vhost_dev_set_config_notifier`).
To ensure this initialization, it’s better to allocate the entire
`CryptoDevBackendVhost` structure (which includes `vhost_dev`) using
`g_mem0()`, following the same approach used for other vhost devices,
such as in `vhost_net_init()`.
Fixes: 042cea274c ("cryptodev: add vhost-user as a new cryptodev backend")
Cc: [email protected]
Reported-by: [email protected]
Signed-off-by: Stefano Garzarella <[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 83cb18ac4500f3a14067b19408705068647cb0c5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 39c62e22e15b427e257af69796619e2064b27add
https://github.com/qemu/qemu/commit/39c62e22e15b427e257af69796619e2064b27add
Author: Max Chou <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: rvv: Fix unexpected behavior of vector reduction instructions
when vl is 0
According to the Vector Reduction Operations section in the RISC-V "V"
Vector Extension spec,
"If vl=0, no operation is performed and the destination register is not
updated."
The vd should be updated when vl is larger than 0.
Fixes: fe5c9ab1fc ("target/riscv: vector single-width integer reduction
instructions")
Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR")
Signed-off-by: Max Chou <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit ffd455963f230c7dc04965609d6675da687a5a78)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f7703cc6a7d7d2ce46f02b4e146ada3d807a5150
https://github.com/qemu/qemu/commit/f7703cc6a7d7d2ce46f02b4e146ada3d807a5150
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/riscv/debug.c
Log Message:
-----------
target/riscv/debug.c: use wp size = 4 for 32-bit CPUs
The mcontrol select bit (19) is always zero, meaning our triggers will
always match virtual addresses. In this condition, if the user does not
specify a size for the trigger, the access size defaults to XLEN.
At this moment we're using def_size = 8 regardless of CPU XLEN. Use
def_size = 4 in case we're running 32 bits.
Fixes: 95799e36c1 ("target/riscv: Add initial support for the Sdtrig extension")
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 3fba76e61caa46329afc399b3ecaaba70c8b0a4e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2a13da177eeaf35a550f025797f0f36dc79af6e7
https://github.com/qemu/qemu/commit/2a13da177eeaf35a550f025797f0f36dc79af6e7
Author: Daniel Henrique Barboza <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: throw debug exception before page fault
In the RISC-V privileged ISA section 3.1.15 table 15, it is determined
that a debug exception that is triggered from a load/store has a higher
priority than a possible fault that this access might trigger.
This is not the case ATM as shown in [1]. Adding a breakpoint in an
address that deliberately will fault is causing a load page fault
instead of a debug exception. The reason is that we're throwing in the
page fault as soon as the fault occurs (end of riscv_cpu_tlb_fill(),
raise_mmu_exception()), not allowing the installed watchpoints to
trigger.
Call cpu_check_watchpoint() in the page fault path to search and execute
any watchpoints that might exist for the address, never returning back
to the fault path. If no watchpoints are found cpu_check_watchpoint()
will return and we'll fall-through the regular path to
raise_mmu_exception().
[1] https://gitlab.com/qemu-project/qemu/-/issues/2627
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2627
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit c86edc547692d812d1dcc04220c38310be2c00c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b22ba87b98e728a80897aa2411e8a89b84ad30b5
https://github.com/qemu/qemu/commit/b22ba87b98e728a80897aa2411e8a89b84ad30b5
Author: Rodrigo Dias Correa <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/rtc/goldfish_rtc.c
Log Message:
-----------
goldfish_rtc: Fix tick_offset migration
Instead of migrating the raw tick_offset, goldfish_rtc migrates a
recalculated value based on QEMU_CLOCK_VIRTUAL. As QEMU_CLOCK_VIRTUAL
stands still across a save-and-restore cycle, the guest RTC becomes out
of sync with the host RTC when the VM is restored.
As described in the bug description, it looks like this calculation was
copied from pl031 RTC, which had its tick_offset migration fixed by
Commit 032cfe6a79c8 ("pl031: Correctly migrate state when using -rtc
clock=host").
Migrate the tick_offset directly, adding it as a version-dependent field
to VMState. Keep the old behavior when migrating from previous versions.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2033
Signed-off-by: Rodrigo Dias Correa <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 3521f9cadc29c7d68b73b325ddb46a7acebf6212)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c76d03dd928850bd18fcb5721125fbdee86a76cd
https://github.com/qemu/qemu/commit/c76d03dd928850bd18fcb5721125fbdee86a76cd
Author: Denis Rastyogin <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M block/qed.c
Log Message:
-----------
block/qed: fix use-after-free by nullifying timer pointer after free
This error was discovered by fuzzing qemu-img.
In the QED block driver, the need_check_timer timer is freed in
bdrv_qed_detach_aio_context, but the pointer to the timer is not
set to NULL. This can lead to a use-after-free scenario
in bdrv_qed_drain_begin().
The need_check_timer pointer is set to NULL after freeing the timer.
Which helps catch this condition when checking in bdrv_qed_drain_begin().
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2852
Signed-off-by: Denis Rastyogin <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
(cherry picked from commit 2ad638a3d160923ef3dbf87c73944e6e44bdc724)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4ffa569f32d95f96e0d4d9de4a6b1600b9da064d
https://github.com/qemu/qemu/commit/4ffa569f32d95f96e0d4d9de4a6b1600b9da064d
Author: Patrick Venture <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/gpio/npcm7xx_gpio.c
Log Message:
-----------
hw/gpio: npcm7xx: fixup out-of-bounds access
The reg isn't validated to be a possible register before
it's dereferenced for one case. The mmio space registered
for the gpio device is 4KiB but there aren't that many
registers in the struct.
Cc: [email protected]
Fixes: 526dbbe0874 ("hw/gpio: Add GPIO model for Nuvoton NPCM7xx")
Signed-off-by: Patrick Venture <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 3b2e22c0bbe2ce07123d93961d52f17644562cd7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 12e3833b2981a25169041450084e94a6647daeef
https://github.com/qemu/qemu/commit/12e3833b2981a25169041450084e94a6647daeef
Author: Nicholas Piggin <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/ppc/pnv_occ.c
Log Message:
-----------
ppc/pnv/occ: Fix common area sensor offsets
The commit to fix the OCC common area sensor mappings didn't update the
register offsets to match.
Before this change, skiboot reports:
[ 0.347100086,3] OCC: Chip 0 sensor data invalid
Afterward, there is no error and the sensor_groups directory appears
under /sys/firmware/opal/.
The SLW_IMAGE_BASE address looks like a workaround to intercept firmware
memory accesses, but that does not seem to be required now (and would
have been broken by the OCC common area region mapping change anyway).
So it can be removed.
Fixes: 3a1b70b66b5cb4 ("ppc/pnv: Fix OCC common area region mapping")
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 29c041ca7f8d6910c894788482efff892789dcd2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4ad38ddb2221c2c4cf88d91dadce597bbc581377
https://github.com/qemu/qemu/commit/4ad38ddb2221c2c4cf88d91dadce597bbc581377
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Ignore attempt to pop from empty RX fifo
The SMC91C111 includes an MMU Command register which permits
the guest to remove entries from the RX FIFO. The datasheet
does not specify what happens if the guest tries to do this
when the FIFO is already empty; there are no status registers
containing error bits which might be applicable.
Currently we don't guard at all against pop of an empty
RX FIFO, with the result that we allow the guest to drive
the rx_fifo_len index to negative values, which will cause
smc91c111_receive() to write to the rx_fifo[] array out of
bounds when we receive the next packet.
Instead ignore attempts to pop an empty RX FIFO.
Cc: [email protected]
Fixes: 80337b66a8e7 ("NIC emulation for qemu arm-softmmu")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2780
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 937df81af6757638a7f1908747560dd342947213)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 17a037dd203f4dc4c38862d319ed9ffb7c85b4a3
https://github.com/qemu/qemu/commit/17a037dd203f4dc4c38862d319ed9ffb7c85b4a3
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet numbers
The smc91c111 uses packet numbers as an index into its internal
s->data[][] array. Valid packet numbers are between 0 and 3, but
the code does not generally check this, and there are various
places where the guest can hand us an arbitrary packet number
and cause an out-of-bounds access to the data array.
Add validation of packet numbers. The datasheet is not very
helpful about how guest errors like this should be handled:
it says nothing on the subject, and none of the documented
error conditions are relevant. We choose to log the situation
with LOG_GUEST_ERROR and silently ignore the attempted operation.
In the places where we are about to access the data[][] array
using a packet number and we know the number is valid because
we got it from somewhere that has already validated, we add
an assert() to document that belief.
Cc: [email protected]
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 2fa3a5b9469615d06091cf473d172794148e1248)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7177b99394f380598b2bb4dbdf53e42343a02ace
https://github.com/qemu/qemu/commit/7177b99394f380598b2bb4dbdf53e42343a02ace
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Sanitize packet length on tx
When the smc91c111 transmits a packet, it must read a control byte
which is at the end of the data area and CRC. However, we don't
sanitize the length field in the packet buffer, so if the guest sets
the length field to something large we will try to read past the end
of the packet data buffer when we access the control byte.
As usual, the datasheet says nothing about the behaviour of the
hardware if the guest misprograms it in this way. It says only that
the maximum valid length is 2048 bytes. We choose to log the guest
error and silently drop the packet.
This requires us to factor out the "mark the tx packet as complete"
logic, so we can call it for this "drop packet" case as well as at
the end of the loop when we send a valid packet.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2742
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
[PMD: Update smc91c111_do_tx() as len > MAX_PACKET_SIZE]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit aad6f264add3f2be72acb660816588fe09110069)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5e3607f1083f75766f5b00387fdee47f88588e30
https://github.com/qemu/qemu/commit/5e3607f1083f75766f5b00387fdee47f88588e30
Author: Peter Maydell <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/net/smc91c111.c
Log Message:
-----------
hw/net/smc91c111: Don't allow data register access to overrun buffer
For accesses to the 91c111 data register, the address within the
packet's data frame is determined by a combination of the pointer
register and the offset used to access the data register, so that you
can access data at effectively wider than byte width. The pointer
register's pointer field is 11 bits wide, which is exactly the size
to index a 2048-byte data frame.
We weren't quite getting the logic right for ensuring that we end up
with a pointer value to use in the s->data[][] array that isn't out
of bounds:
* we correctly mask when getting the initial pointer value
* for the "autoincrement the pointer register" case, we
correctly mask after adding 1 so that the pointer register
wraps back around at the 2048 byte mark
* but for the non-autoincrement case where we have to add the
low 2 bits of the data register offset, we don't account
for the possibility that the pointer register is 0x7ff
and the addition should wrap
Fix this bug by factoring out the "get the p value to use as an array
index" into a function, making it use FIELD macro names rather than
hard-coded constants, and having a utility function that does "add a
value and wrap it" that we can use both for the "autoincrement" and
"add the offset bits" codepaths.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2758
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 700d3d6dd41de3bd3f1153e3cfe00b93f99b1441)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 47f1e60d5b055bd185d8b54a6815fa6008955a62
https://github.com/qemu/qemu/commit/47f1e60d5b055bd185d8b54a6815fa6008955a62
Author: Kevin Wolf <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M block/snapshot.c
Log Message:
-----------
block: Zero block driver state before reopening
Block drivers assume in their .bdrv_open() implementation that their
state in bs->opaque has been zeroed; it is initially allocated with
g_malloc0() in bdrv_open_driver().
bdrv_snapshot_goto() needs to make sure that it is zeroed again before
calling drv->bdrv_open() to avoid that block drivers use stale values.
One symptom of this bug is VMDK running into a double free when the user
tries to apply an internal snapshot like 'qemu-img snapshot -a test
test.vmdk'. This should be a graceful error because VMDK doesn't support
internal snapshots.
==25507== Invalid free() / delete / delete[] / realloc()
==25507== at 0x484B347: realloc (vg_replace_malloc.c:1801)
==25507== by 0x54B592A: g_realloc (gmem.c:171)
==25507== by 0x1B221D: vmdk_add_extent (../block/vmdk.c:570)
==25507== by 0x1B1084: vmdk_open_sparse (../block/vmdk.c:1059)
==25507== by 0x1AF3D8: vmdk_open (../block/vmdk.c:1371)
==25507== by 0x1A2AE0: bdrv_snapshot_goto (../block/snapshot.c:299)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
==25507== Address 0x832f3e0 is 0 bytes inside a block of size 272 free'd
==25507== at 0x4846B83: free (vg_replace_malloc.c:989)
==25507== by 0x54AEAC4: g_free (gmem.c:208)
==25507== by 0x1AF629: vmdk_close (../block/vmdk.c:2889)
==25507== by 0x1A2A9C: bdrv_snapshot_goto (../block/snapshot.c:290)
==25507== by 0x205C77: img_snapshot (../qemu-img.c:3500)
==25507== by 0x58FA087: (below main) (libc_start_call_main.h:58)
This error was discovered by fuzzing qemu-img.
Cc: [email protected]
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2853
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2851
Reported-by: Denis Rastyogin <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit b75c5f9879166b86ed7c48b772fdcd0693e8a9a3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a995b88630c73943eda9d9fe4216b1c55c52c630
https://github.com/qemu/qemu/commit/a995b88630c73943eda9d9fe4216b1c55c52c630
Author: Greg Kurz <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M docs/devel/build-system.rst
M docs/devel/kconfig.rst
Log Message:
-----------
docs: Rename default-configs to configs
This was missed at the time.
Fixes: 812b31d3f91 ("configs: rename default-configs to configs and reorganise")
Signed-off-by: Greg Kurz <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 48170c2d865a5937092b1384421b01cd38113042)
(Mjt: context fix in docs/devel/kconfig.rst)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 052bb76c21b98a0e10a93d696c054fcaed48dc79
https://github.com/qemu/qemu/commit/052bb76c21b98a0e10a93d696c054fcaed48dc79
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M ui/cocoa.m
Log Message:
-----------
ui/cocoa: Temporarily ignore annoying deprecated declaration warnings
These warnings are breaking some build configurations since 2 months
now (https://gitlab.com/qemu-project/qemu/-/issues/2575):
ui/cocoa.m:662:14: error: 'CVDisplayLinkCreateWithCGDisplay' is deprecated:
first deprecated in macOS 15.0 - use NSView.displayLink(target:selector:),
NSWindow.displayLink(target:selector:), or
NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
662 | if (!CVDisplayLinkCreateWithCGDisplay(display, &displayLink))
{
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:89:20:
note: 'CVDisplayLinkCreateWithCGDisplay' has been explicitly marked deprecated
here
89 | CV_EXPORT CVReturn CVDisplayLinkCreateWithCGDisplay(
| ^
ui/cocoa.m:663:29: error: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod'
is deprecated: first deprecated in macOS 15.0 - use
NSView.displayLink(target:selector:), NSWindow.displayLink(target:selector:),
or NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
663 | CVTime period =
CVDisplayLinkGetNominalOutputVideoRefreshPeriod(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:182:18:
note: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' has been explicitly
marked deprecated here
182 | CV_EXPORT CVTime CVDisplayLinkGetNominalOutputVideoRefreshPeriod(
CVDisplayLinkRef CV_NONNULL displayLink );
| ^
ui/cocoa.m:664:13: error: 'CVDisplayLinkRelease' is deprecated: first
deprecated in macOS 15.0 - use NSView.displayLink(target:selector:),
NSWindow.displayLink(target:selector:), or
NSScreen.displayLink(target:selector:) [-Werror,-Wdeprecated-declarations]
664 | CVDisplayLinkRelease(displayLink);
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:249:16:
note: 'CVDisplayLinkRelease' has been explicitly marked deprecated here
249 | CV_EXPORT void CVDisplayLinkRelease( CV_RELEASES_ARGUMENT
CVDisplayLinkRef CV_NULLABLE displayLink );
| ^
3 errors generated.
For the next release, ignore the warnings using #pragma directives.
At least until we figure the correct new API usage.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Phil Dennis-Jordan <[email protected]>
Tested-by: Phil Dennis-Jordan <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 9cf6e41fe293dd56089faac94c36ff5cb3d96726)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 91126b665104b3f526ea23449e38b5f206b81d84
https://github.com/qemu/qemu/commit/91126b665104b3f526ea23449e38b5f206b81d84
Author: Joe Komlodi <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M util/cacheflush.c
Log Message:
-----------
util/cacheflush: Make first DSB unconditional on aarch64
On ARM hosts with CTR_EL0.DIC and CTR_EL0.IDC set, this would only cause
an ISB to be executed during cache maintenance, which could lead to QEMU
executing TBs containing garbage instructions.
This seems to be because the ISB finishes executing instructions and
flushes the pipeline, but the ISB doesn't guarantee that writes from the
executed instructions are committed. If a small enough TB is created, it's
possible that the writes setting up the TB aren't committed by the time the
TB is executed.
This function is intended to be a port of the gcc implementation
(https://github.com/gcc-mirror/gcc/blob/85b46d0795ac76bc192cb8f88b646a647acf98c1/libgcc/config/aarch64/sync-cache.c#L67)
which makes the first DSB unconditional, so we can fix the synchronization
issue by doing that as well.
Cc: [email protected]
Fixes: 664a79735e4deb1 ("util: Specialize flush_idcache_range for aarch64")
Signed-off-by: Joe Komlodi <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit e6c38d2ab55d66c74ceade5699e22cabe9058d22)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8ce09b596891dcf1a4e8c1b5f87261bb3919ebe9
https://github.com/qemu/qemu/commit/8ce09b596891dcf1a4e8c1b5f87261bb3919ebe9
Author: Richard Henderson <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/translate-a64.c
M target/arm/translate-a64.h
M target/arm/translate.h
Log Message:
-----------
target/arm: Make DisasContext.{fp, sve}_access_checked tristate
The check for fp_excp_el in assert_fp_access_checked is
incorrect. For SME, with StreamingMode enabled, the access
is really against the streaming mode vectors, and access
to the normal fp registers is allowed to be disabled.
C.f. sme_enabled_check.
Convert sve_access_checked to match, even though we don't
currently check the exception state.
Cc: [email protected]
Fixes: 3d74825f4d6 ("target/arm: Add SME enablement checks")
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 298a04998fa4a6dc977abe9234d98dfcdab98423)
(Mjt: minor context fix in target/arm/tcg/translate.h,
target/arm/tcg/translate-a64.c is target/arm/translate-a64.c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1221002c0af6a2fe6b2fc851868327d888b1595b
https://github.com/qemu/qemu/commit/1221002c0af6a2fe6b2fc851868327d888b1595b
Author: Richard Henderson <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M target/arm/translate-a64.c
Log Message:
-----------
target/arm: Simplify pstate_sm check in sve_access_check
In StreamingMode, fp_access_checked is handled already.
We cannot fall through to fp_access_check lest we fall
foul of the double-check assertion.
Cc: [email protected]
Fixes: 285b1d5fcef ("target/arm: Handle SME in sve_access_check")
Signed-off-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
[PMM: move declaration of 'ret' to top of block]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit cc7abc35dfa790ba6c20473c03745428c1c626b6)
(Mjt: target/arm/tcg/translate-a64.c is target/arm/translate-a64.c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3d12a79a6cba80461103455b2c57b1e8445b0c4f
https://github.com/qemu/qemu/commit/3d12a79a6cba80461103455b2c57b1e8445b0c4f
Author: Konstantin Shkolnyy <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M hw/virtio/vhost-shadow-virtqueue.c
Log Message:
-----------
vdpa: Fix endian bugs in shadow virtqueue
VDPA didn't work on a big-endian machine due to missing/incorrect
CPU<->LE data format conversions.
Signed-off-by: Konstantin Shkolnyy <[email protected]>
Message-Id: <[email protected]>
Fixes: 10857ec0ad ("vhost: Add VhostShadowVirtqueue")
Acked-by: Eugenio Pérez <[email protected]>
Tested-by: Lei Yang <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 50e9754149066dc91f58405d3378b589098cb408)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 33c255bb95945045de188a12c39fe485bd673d3e
https://github.com/qemu/qemu/commit/33c255bb95945045de188a12c39fe485bd673d3e
Author: Konstantin Shkolnyy <[email protected]>
Date: 2025-03-22 (Sat, 22 Mar 2025)
Changed paths:
M net/vhost-vdpa.c
Log Message:
-----------
vdpa: Allow vDPA to work on big-endian machine
Add .set_vnet_le() function that always returns success, assuming that
vDPA h/w always implements LE data format. Otherwise, QEMU disables vDPA and
outputs the message:
"backend does not support LE vnet headers; falling back on userspace virtio"
Reviewed-by: Michael S. Tsirkin <[email protected]>
Acked-by: Eugenio Pérez <[email protected]>
Signed-off-by: Konstantin Shkolnyy <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit b027f55a994af885a7a498a40373a2dcc2d8b15e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a7f1eb5e2723868b3f79b543f42d72f353497522
https://github.com/qemu/qemu/commit/a7f1eb5e2723868b3f79b543f42d72f353497522
Author: Nicholas Piggin <[email protected]>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M target/ppc/cpu_init.c
Log Message:
-----------
target/ppc: Fix e200 duplicate SPRs
DSRR0/1 registers are in the BookE ISA not e200 specific, so
remove the duplicate e200 register definitions.
Cc: Roman Kapl <[email protected]>
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2768
Fixes: 0e3bf4890906 ("ppc: add DBCR based debugging")
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 73c0c904fc99e2ceecbbded84ec76d40d3f2daae)
(Mjt: context fix for
v9.0.0-935-g581eea5d656b "target/ppc: Split off common embedded TLB init")
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 88f98ad83a4f2a174791579485ec133b7598d039
https://github.com/qemu/qemu/commit/88f98ad83a4f2a174791579485ec133b7598d039
Author: Jamin Lin <[email protected]>
Date: 2025-03-24 (Mon, 24 Mar 2025)
Changed paths:
M hw/misc/aspeed_hace.c
Log Message:
-----------
hw/misc/aspeed_hace: Fix buffer overflow in has_padding function
The maximum padding size is either 64 or 128 bytes and should always be smaller
than "req_len". If "padding_size" exceeds "req_len", then
"req_len - padding_size" underflows due to "uint32_t" data type, leading to a
large incorrect value (e.g., `0xFFXXXXXX`). This causes an out-of-bounds memory
access, potentially leading to a buffer overflow.
Added a check to ensure "padding_size" does not exceed "req_len" before
computing "pad_offset". This prevents "req_len - padding_size" from underflowing
and avoids accessing invalid memory.
Signed-off-by: Jamin Lin <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Fixes: 5cd7d8564a8b563da724b9e6264c967f0a091afa ("aspeed/hace: Support AST2600
HACE ")
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 78877b2e06464f49f777e086845e094ea7bc82ef)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 40b933fca98943d9f14b9c81ba4184b4714df9ad
https://github.com/qemu/qemu/commit/40b933fca98943d9f14b9c81ba4184b4714df9ad
Author: Michael Tokarev <[email protected]>
Date: 2025-03-26 (Wed, 26 Mar 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 7.2.17 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/044e1dd76bf5...40b933fca989
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
