Jamin Lin [Mon, 25 May 2026 05:30:49 +0000 (05:30 +0000)]
docs/system/arm/aspeed: Add AST1040 Bridge IC evaluation board
Update the Aspeed AST10x0 documentation to include the
AST1040 evaluation board and clarify the AST10x0 family
classification.
The documentation now describes:
- AST1030 and AST1040 as Bridge IC devices
- AST1060 as a Platform Root of Trust processor
- AST1040 Cortex-M4F CPU frequency running at 400 MHz
Also add the ast1040-evb machine entry to the supported
AST10x0 SoC based machine list.
Jamin Lin [Mon, 25 May 2026 05:30:46 +0000 (05:30 +0000)]
hw/arm/aspeed: Add AST1040 EVB machine model
AST1040 is the next-generation device following AST1030 and is
primarily designed as a bridge/BIC controller platform. Introduce
a dedicated AST1040 EVB machine implementation for firmware
development and validation.
Although the existing ast10x0 EVB machine code already provides
a reusable minibmc initialization flow, AST1040 requires
different platform settings, including:
- Different SYSCLK frequency
- Different internal flash size
To avoid overloading the existing AST1030-specific helper,
introduce a separate aspeed_bic_machine_init() implementation in
a dedicated source file.
Jamin Lin [Mon, 25 May 2026 05:30:45 +0000 (05:30 +0000)]
hw/arm/aspeed: Introduce AST1040 A0 SoC model
The AST1040 is based on an ARM Cortex-M4F CPU core. Since QEMU
currently does not provide Cortex-M4F support, use the existing
Cortex-M4 CPU model as a temporary replacement.
This initial implementation provides the basic infrastructure
required to boot firmware and run a minimal firmware shell,
including:
- ARM Cortex-M4 CPU integration
- NVIC interrupt controller support
- Internal HyperRAM and SRAM memory regions
- SCU integration
- UART devices and interrupt wiring
AST1040 SCU behavior is compatible with the AST2700 SCUIO model,
so reuse the existing AST2700 SCUIO implementation directly
instead of introducing another identical SCU model. This reduces
duplicate code and helps minimize long-term codebase maintenance.
Several peripherals are currently modeled as unimplemented
devices and can be added incrementally in future updates.
Jamin Lin [Mon, 25 May 2026 05:30:43 +0000 (05:30 +0000)]
hw/arm/aspeed: Consolidate secure SRAM into SRAM array
Some Aspeed SoCs contain multiple SRAM regions with different
sizes and MMIO mappings, such as internal SRAM and secure SRAM.
The current implementation models secure SRAM separately from the
generic SRAM representation, which complicates future multi-SRAM
support and expansion.
Increase ASPEED_SRAM_NUM to 2 and migrate secure SRAM to use the
common SRAM array representation. Rename the secure SRAM memmap
entry to ASPEED_DEV_SRAM1 and update AST10x0 to initialize both
SRAM regions through sram[] and sram_size[].
This unifies SRAM-like regions under a common representation and
prepares for future SoCs with additional SRAM regions.
Jamin Lin [Mon, 25 May 2026 05:30:42 +0000 (05:30 +0000)]
hw/arm/aspeed: Rename SRAM memmap entry for multi-SRAM support
Some Aspeed SoCs contain multiple SRAM regions with different
MMIO mappings, such as internal SRAM and secure SRAM.
Prepare for future multi-SRAM support by renaming the SRAM
memmap entry from ASPEED_DEV_SRAM to ASPEED_DEV_SRAM0.
This makes the numbering explicit and aligns with the
array-based SRAM representation introduced previously.
Jamin Lin [Mon, 25 May 2026 05:30:40 +0000 (05:30 +0000)]
hw/arm/aspeed: Convert SRAM size definition to array type
Prepare the Aspeed SoC model for future platforms that may contain
multiple SRAM regions with different sizes and MMIO mappings.
The current implementation stores SRAM size information in a single
sram_size field, which limits extensibility when additional SRAM
instances are introduced.
Convert sram_size into an array-based definition and update all
existing users to reference sram_size[0]. This aligns with the
previous SRAM MemoryRegion array conversion and provides a scalable
foundation for supporting multiple SRAM regions in future SoCs.
Jamin Lin [Mon, 25 May 2026 05:30:39 +0000 (05:30 +0000)]
hw/arm/aspeed: Convert SRAM MemoryRegion to array type
Several kinds of RAM are supported across Aspeed SoCs, including
SRAM, SDRAM, HyperRAM, secure SRAM, and generic SRAM. In addition,
different SoCs may expose multiple SRAM regions at different MMIO
addresses.
The current implementation models SRAM with a single MemoryRegion
instance, which makes future expansion cumbersome when additional
SRAM types or regions are introduced.
Prepare for future SoC designs by converting the SRAM MemoryRegion
from a single object into an array-based structure. This change
introduces ASPEED_SRAM_NUM and converts existing SRAM users to
reference sram[0].
Stefan Hajnoczi [Mon, 25 May 2026 17:57:57 +0000 (13:57 -0400)]
Merge tag 'linux-user-next-pull-request' of https://github.com/hdeller/qemu-hppa into staging
linux-user updates from Matt Turner
Various linux-user updates and fixes from Matt Turner regarding VDSO and
coredump support for hppa, mips, mips64, riscv and sh4.
# -----BEGIN PGP SIGNATURE-----
#
# iHUEABYKAB0WIQS86RI+GtKfB8BJu973ErUQojoPXwUCahL6kgAKCRD3ErUQojoP
# XwwSAP9a27pKepFjViB3WFe7/CC29m7aVE3EZeyEbEyZnpoPAgD/T+wca+TRdhHm
# 6TCaG3eNOUnWL4UvCOU8Vhdk1BXMAQ0=
# =n+8n
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 24 May 2026 09:18:10 EDT
# gpg: using EDDSA key BCE9123E1AD29F07C049BBDEF712B510A23A0F5F
# gpg: Good signature from "Helge Deller <deller@gmx.de>" [unknown]
# gpg: aka "Helge Deller <deller@kernel.org>" [unknown]
# gpg: aka "Helge Deller <deller@debian.org>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 4544 8228 2CD9 10DB EF3D 25F8 3E5F 3D04 A7A2 4603
# Subkey fingerprint: BCE9 123E 1AD2 9F07 C049 BBDE F712 B510 A23A 0F5F
* tag 'linux-user-next-pull-request' of https://github.com/hdeller/qemu-hppa:
linux-user/sh4: add VDSO support for sh4 and sh4eb
linux-user/riscv: add coredump support
linux-user/mips: use tswap32 in elf_core_copy_regs
linux-user/mips64: fix mipsn32 elf_core_copy_regs entry width
linux-user/mips64: fix elf_core_copy_regs register layout in core files
linux-user/hppa: add coredump support
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'pull-ppc-for-11.1-0523-20260523' of https://gitlab.com/harshpb/qemu:
ppc/spapr: Make Power11 as default cpu for pseries
ppc/pnv: Make PowerNV11 as the default powernv machine
target/ppc/kvm: Fix const violation when trimming CPU alias suffix
ppc/pnv: Fix uninitialized MpiplProcDumpArea struct
ppc/spapr: Skip system reset for quiesced CPUs
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
qemu_laio_process_completions() wraps its body in defer_call_begin /
defer_call_end. Inside the section, completion callbacks wake coroutines
that queue new aiocbs; laio_do_submit() defers laio_deferred_fn. At the
bottom of qemu_laio_process_completions() the defer_call_end() fires
laio_deferred_fn, which calls ioq_submit(), closing the cycle:
When io_submit(2) returns asynchronously (O_DIRECT) the cycle
terminates in one extra frame: the fresh aiocb is still in flight, no
completion is drained, no coroutine wakes, no new submission queues.
When submissions complete synchronously (non-O_DIRECT, or per-descriptor
drivers such as vmdk) each level enqueues more work for the next
defer_call_end() to drain, so recursion grows without bound and QEMU
crashes with SIGSEGV on the thread guard page.
The cycle was closed by two performance commits, each correct in
isolation:
076682885d ("block/linux-aio: convert to blk_io_plug_call() API")
-- introduced laio_deferred_fn and wired
laio_do_submit -> defer_call(laio_deferred_fn, s).
84d61e5f36 ("virtio: use defer_call() in virtio_irqfd_notify()")
-- added defer_call_begin/end around qemu_laio_process_completions
so virtio-irqfd notifications batch across a completion pass.
The supported aio=native + cache=none pairing keeps submissions
asynchronous, so the cycle stays bounded; nothing in the code enforces
that contract. Observed in production as a SIGSEGV during a backup job
configured with --cached + aio=native; reproducible on upstream with
qemu-io against vmdk.
Cap ioq_submit() recursion with a counter on LaioQueue, which is only
accessed from the AioContext home thread. On overflow, return without
submitting. The pending work is drained by s->completion_bh, which
qemu_laio_process_completions() has already scheduled on entry -- no
work is lost; one event-loop round-trip of latency is paid only when
the bound is hit, which cannot happen on a supported configuration.
Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Kevin Wolf <kwolf@redhat.com> CC: Hanna Reitz <hreitz@redhat.com> CC: Stefan Hajnoczi <stefanha@redhat.com> CC: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <20260520142503.251959-2-den@openvz.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Jinjie Ruan [Wed, 14 Jan 2026 01:32:57 +0000 (09:32 +0800)]
mc146818rtc: Fix get_guest_rtc_ns() overflow bug
In get_guest_rtc_ns(), "s->base_rtc" is uint64_t, which multiplied by
"NANOSECONDS_PER_SECOND" may overflow the uint64_t type, which will
cause the QEMU Linux Virtual Machine's RTC time to jump and in turn
triggers a kernel Soft Lockup and ultimately leads to a crash.
Fix it by avoiding adding s->base_rtc in get_guest_rtc_ns_offset(),
because get_guest_rtc_ns() is used either take the remainder of
NANOSECONDS_PER_SECOND or take the quotient of NANOSECONDS_PER_SECOND.
Magnus Kulke [Tue, 21 Apr 2026 05:21:54 +0000 (05:21 +0000)]
accel/mshv: implement cpu_thread_is_idle() hook
In MSHV the hypervisor APIC is always used, so we to implement this hook
to make sure the AP's vcpu thread is not blocked waiting for an INIT SIPI
by the BSP. Without this change soft reboots with -smp cpus>=2 will
hang.
Paolo Bonzini [Fri, 15 May 2026 10:10:22 +0000 (12:10 +0200)]
apic: fix delivery bitmask with modified xAPIC ids
Self-IPIs (or all-but-self IPIs) in QEMU can cause a out-of-bounds access
to deliver_bitmask, because the access uses the APIC ID register which
is writable by the guest. However, foreach_apic uses the delivery
bitmask indexes to look up the local_apics[] array, which is indexed
by *initial* APIC id. Using the right id fixes both a possible heap
write overflow if the modified APIC id is too large for max_apic_words,
and a mis-delivery of both self and all-but-self IPIs.
Reported-by: Wei Che Kao <skps96g313.cs10@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 15 May 2026 09:01:00 +0000 (11:01 +0200)]
lsi53c895a: fix use-after-free of cancelled request
When processing the Message Out phase, the lsi53c895a controller
can cancel a request and the continue by processing more messages.
When this happens, it is important that a cancelled request is not
processed further, because scsi_req_cancel can cause the request
to be freed.
Right now this is happening in two cases, but not when cancelling
the entire queue of requests after an ABORT, CLEAR QUEUE or
BUS DEVICE RESET message. In that case, a subsequent ABORT TAG
message can use a dangling current_req.
There are three possible fixes:
- add a missing check inside the loop, clearing current_req
if p->req == current_req. This is obvious but complicates the
code inside the foreach loop.
- change the conditional prior to the loop from "if (s->current)"
to "if (current_req)". This would work, because s->current != NULL
implies current_req != NULL, and would clear current_req correctly.
However it is less obvious because the point of the code
is to clear the entire queue, which consists of s->current
and s->queue; current_req is not special here.
- delay the retrieval of current_req until an ABORT TAG message
is seen. This is the most correct option, because the SCSI
protocol only deals with tags; requests are a QEMU concept
that only makes sense for the purpose of calling into the
SCSI layer.
Reported-by: Wei Che Kao <skps96g313.cs10@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Dongwon Kim [Wed, 20 May 2026 00:26:45 +0000 (17:26 -0700)]
ui/gtk: Fix focus loss on re-attachment with single VC
When QEMU is launched with a single virtual console (e.g., using
--nodefaults), detaching and then closing the detached window leaves
the main window's notebook without an active focus target which makes
keyboard unfunctional on re-attached VC.
Fix this by explicitly calling gtk_widget_grab_focus on the active
VC's focus widget during the window close handler.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
Message-ID: <20260520002645.1910740-1-dongwon.kim@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Add the Facebook Anacapa BMC machine. The I2C topology is based on the
Linux kernel device tree [1]. Hardware strap register values are taken
from real hardware.
A functional test is included using the OpenBMC image built from [2],
similar to the tests for bletchley-bmc and catalina-bmc.
Facebook OpenBMC Images include an early script [1] that lowers the
console log level to warning. This suppresses the "Hostname set to"
message from the serial console. Introduce FacebookAspeedTest (a
subclass of AspeedTest), that waits for login prompt instead. Update
bletchley-bmc and catalina-bmc to use the new class.
This is also used by the anacapa-bmc machine introduced in the following
patch.
Cédric Le Goater [Tue, 12 May 2026 20:58:36 +0000 (22:58 +0200)]
hw/misc/aspeed_scu: Fix AST2600_RNG definitions
Commit e09cf36321f6 ("hw: aspeed_scu: Add AST2600 support") introduced
a typo on the definitions of the Random Number Generator registers.
Fix that.
The implementation of RNG_CTRL and RNG_DATA should be rechecked on HW
since the QEMU implementation always generates random data, regardless
of RNG_CTRL. A comment in aspeed_ast2600_scu_read() admits uncertainty
about the behavior :
/*
* On hardware, RNG_DATA works regardless of the state of the
* enable bit in RNG_CTRL
*
* TODO: Check this is true for ast2600
*/
Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/2350 Fixes: e09cf36321f6 ("hw: aspeed_scu: Add AST2600 support") Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
Akihiko Odaki [Wed, 20 May 2026 06:47:49 +0000 (15:47 +0900)]
ui/console: Add qemu_text_console_put_linux()
Add a text console helper that accepts Linux input key codes and use it
as the common implementation for qemu_text_console_put_qcode(). This lets
callers that already use Linux key codes avoid converting them back to
QKeyCode.
Akihiko Odaki [Wed, 20 May 2026 06:47:48 +0000 (15:47 +0900)]
ui/input: Prohibit sending KEY_RESERVED
xenfb and virtio-input no longer need key mapping because they operate
on Linux key codes, but removing the key mapping code loses the ability
to filter out KEY_RESERVED. Drop KEY_RESERVED at the common input event
entry point so the logic is shared by both devices and no downstream
input handler receives KEY_RESERVED accidentally.
Akihiko Odaki [Wed, 20 May 2026 06:47:47 +0000 (15:47 +0900)]
ui/input: Use Linux key codes for internal key events
Linux input key codes are a better internal representation than
QKeyCode:
- With Linux input key codes as the internal representation, keys
previously lost solely because the middle layer between event sources
and sinks used QKeyCode will be preserved, since Linux key codes
cover all keys that those sources and sinks use. For example,
KEY_KPJPCOMMA cannot be represented with QKeyCode, but it is widely
supported by event sources and sinks since it is included in linux,
atset1, atset2, usb, x11, osx, qnum (derived from atset1),
xorgxquartz, and xorgevdev (derived from linux).
- They make it possible to pass through Linux host key codes to Linux
guests to preserve all key inputs.
- They simplify consumers by avoiding QKeyCode aliases, namely
asterisk/kp_multiply and sysrq/print.
Akihiko Odaki [Wed, 20 May 2026 06:47:46 +0000 (15:47 +0900)]
ui/input: Store QKeyCode directly in QemuInputKeyEvent
Since commit af07e5ff02ae ("ui: convert key events to QKeyCodes
immediately"), all internal key events are expected to be represented as
QKeyCode. Replace KeyValue in QemuInputKeyEvent with QKeyCode to enforce
that and simplify key code retrieval.
Akihiko Odaki [Wed, 20 May 2026 06:47:45 +0000 (15:47 +0900)]
ui/input: Remove QAPI wrappers from QemuInputEvent
QAPI represents union members with wrapper structs and pointer
indirections. They are useful at the QMP boundary, but unnecessary for
QEMU's internal input events and make handlers more verbose.
Define QemuInputEvent as a plain internal tagged union and convert input
handlers, queues, and replay code to access payloads directly.
Heechan Kang [Tue, 12 May 2026 09:55:43 +0000 (10:55 +0100)]
ui: fix validation of VNC extended clipboard data length
QEMU's VNC extended clipboard handler inflates a client-controlled
compressed clipboard payload. The code checks the declared text size
against the total inflated buffer size:
The correct bound is the remaining data length after the 4-byte length
field, not the total inflated buffer length.
As a result, a VNC client can make QEMU copy up to 3 bytes past the end
of the inflated heap buffer. With a second VNC client, those copied
bytes are observable through the normal VNC extended clipboard PROVIDE
path.
Fixes: CVE-2026-8343 Reported-by: Heechan Kang <gganji11@naver.com> Reported-by: Feifan Qian <bea1e@proton.me> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Heechan Kang <gganji11@naver.com>
[DB: added #include and 'return' statements] Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260512095543.459949-1-berrange@redhat.com>
ui/vnc: fix OOB read updating VNC update frequency stats
Incorrect loop bounds in vnc_update_freq result in iterating past the
last row and past the last column in the VNC stats array. With suitably
chosen dimensions this could be a OOB read that accesses memory beyond
the VncDisplay struct that the stats array is embedded in.
Should this hit a guard page, it could trigger a guest crash. If it
does not, then the VNC frequency stats will be updated with garbage.
Fixes: CVE-2026-48003 Reported-by: boy juju <agx1657748706@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260521103353.1645561-5-berrange@redhat.com>
Incorrect calculation of the boundary condition when tracking lossy
rectangles in the worker thread will result in an OOB write which
can corrupt further worker state, and/or trigger any guard pages
that may lie beyond the VncWorker struct. This can be triggered
through careful choice of the display resolution in the guest
OS by an unprivileged user.
Fixes: CVE-2026-48002 Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260521103353.1645561-4-berrange@redhat.com>
[Marc-André - added assert() suggest by philmd@linaro.org] Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
If VNC_MAX_WIDTH / VNC_MAX_HEIGHT are not an exact multiple of
VNC_STAT_REC, the COLS/ROWS will be undersized by 1.
Unfortunately:
#define VNC_MAX_HEIGHT 2160
is not a multiple of 64, so there is potential for OOB reads and
writes in the 'stats' array, if the guest surface is over 2112
pixels in height. An array overflow occurs when vnc_update_stats()
records new statistics, either scribbling over data later in the
VncDisplay struct that 'stats' is embedded in, or performing an
OOB write on the allocated struct memory.
Fixes: CVE-2026-48002 Reported-by: boy juju <agx1657748706@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260521103353.1645561-3-berrange@redhat.com>
ui/vnc: fix OOB read access in VNC SASL mechname array
When reading the SASL mechname array off the VNC connection, if
malicious, the received data may contain embedded NULs. If this
happens the memory buffer returned by g_strndup may be shorter
than the original data. Unfortunately the code continued to
index into this buffer with an offset equal to the original
length. This is a potential OOB read of the array.
Fixes: 5847d9e1 (ui/vnc: simplify and avoid strncpy) Reported-by: boy juju <agx1657748706@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20260521103353.1645561-2-berrange@redhat.com>
Peter Maydell [Tue, 12 May 2026 10:42:10 +0000 (11:42 +0100)]
ui/vt100: Take byte as uint8_t in bh_utf8_decode()
The bh_utf8_decode() UTF8 decoder takes its next byte as a "uint32_t
byte" parameter, but it assumes it to be in bounds as it immediately
indexes into its array with it.
Use "uint8_t" as the argument type instead. This moves us away from
the upstream implementation slightly, but it is the same type as
we use in the one callsite, and it makes it clear that we can't
be indexing off the end of the array with this guest-derived data.
This probably helps make Coverity a bit happier (CID 1659590).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260512104210.3330835-3-peter.maydell@linaro.org>
Peter Maydell [Tue, 12 May 2026 10:42:09 +0000 (11:42 +0100)]
ui/vt100: Standardize on uint8_t for "ch" byte variables
The vt100 code is rather confused about how it handles bytes of data
to be sent to the terminal:
* vt100_input() takes a buffer of uint8_t
* each byte is passed to vt100_putchar(), which takes "int ch"
* that calls vt100_put_one(), which also takes "int ch"
* vt100_put_one() sets TextCell::ch, which is uint8_t again
* various places pass the TextCell:ch value to vt100_putcharxy(),
which takes "int ch" again, but uses it unchecked as an
index into a 256-entry array
This confuses Coverity (e.g. CID 1659590) and the reader, who may be
unsure whether the "int" variable really does hold only valid byte
values 0..255 and whether we need to bounds-check before doing array
dereferences.
Standardize on keeping known-byte data in uint8_t all the way
through.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20260512104210.3330835-2-peter.maydell@linaro.org>
Matt Turner [Sat, 23 May 2026 11:41:28 +0000 (07:41 -0400)]
linux-user/sh4: add VDSO support for sh4 and sh4eb
Provides replacement VDSO with sigreturn trampolines
(__kernel_sigreturn, __kernel_rt_sigreturn) and syscall stubs
(clock_gettime, clock_gettime64, clock_getres, gettimeofday).
Both LE and BE blobs are committed and selected at compile time via
TARGET_BIG_ENDIAN. The BE variant requires an sh4eb-unknown-linux-gnu
toolchain; sh4-unknown-linux-gnu does not support -mb.
Matt Turner [Thu, 21 May 2026 18:43:21 +0000 (14:43 -0400)]
linux-user/riscv: add coredump support
Define HAVE_ELF_CORE_DUMP and target_elf_gregset_t in target_elf.h,
mirroring struct user_regs_struct: pc followed by x1 (ra) through
x31 (t6). Implement elf_core_copy_regs() in elfload.c to populate
the gregset from CPURISCVState.
Without this, bprm->core_dump is NULL for RISC-V targets. When a
guest signal goes unhandled, dump_core_and_abort() skips the core
write and falls through to die_with_signal(), which re-raises the
signal to the host. The host kernel then writes an x86-64 core file
for the qemu-riscv64 process instead of a RISC-V guest core.
Signed-off-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
For mipsn32 (TARGET_ABI32=y, TARGET_LONG_BITS=64):
abi_ulong = uint32_t (4 bytes) — for pointers and ABI-sized fields
target_ulong = uint64_t (8 bytes) — for general-purpose registers
linux-user/elfload.c allocates target_elf_prstatus using the
mips64/target_elf.h definition where target_elf_gregset_t has
target_ulong reserved[45] (8 bytes each, 360 bytes total).
However, in linux-user/mips64/elfload.c, #include "target_elf.h" inside
the included mips/elfload.c resolves to mips/target_elf.h (compiler
searches the file's own directory first), where the union uses abi_ulong
reserved[45]. For mipsn32 this gives 4-byte entries (180 bytes), not
the 8-byte entries (360 bytes) that elfload.c actually allocated.
Writing via r->reserved[34] therefore lands at byte offset 34*4=136
instead of the correct 34*8=272, silently zeroing the EPC in the core
file.
Fix by casting the pointer to target_ulong * so writes always use 8-byte
slots and land at the offsets matching the allocated layout.
This does not change behavior for mips64 (N64) where abi_ulong already
equals target_ulong (both 8 bytes).
Signed-off-by: Matt Turner <mattst88@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Helge Deller <deller@gmx.de>
Matt Turner [Thu, 21 May 2026 18:41:01 +0000 (14:41 -0400)]
linux-user/mips64: fix elf_core_copy_regs register layout in core files
mips64/elfload.c uses #include "../mips/elfload.c" to share code. When
the compiler processes mips/elfload.c the quoted #include "target_elf.h"
resolves relative to the including file's directory, so it picks up
mips/target_elf.h instead of mips64/target_elf.h. mips/target_elf.h
pulls in mips/target_ptrace.h, whose target_pt_regs has a pad0[6] field
before regs[]. As a result elf_core_copy_regs writes:
r->pt.regs[i] -> reserved[6+i] (shifted by 6 from the correct index)
r->pt.cp0_epc -> reserved[40] (correct mips64 N64 index is 34)
The Linux kernel and glibc both use the mips64 N64 layout (no pad0): EPC
at reserved[34]. Debuggers and libunwind reading the core with N64
constants therefore see a completely wrong register set — EPC points to
GP, RA holds the branch target instead of the link address, etc.
Fix by:
- Guarding the mips32 elf_core_copy_regs in mips/elfload.c with #ifndef
TARGET_MIPS64 so it is not compiled for mips64/mipsn32 targets.
- Providing a mips64-specific elf_core_copy_regs in mips64/elfload.c
that writes directly to r->reserved[i] with the correct N64 indices,
bypassing the struct field names that are tainted by the wrong header
include.
The mipsn32 (TARGET_ABI_MIPSN32) and mips64el targets are covered by the
same mips64/elfload.c and benefit from the same fix.
Signed-off-by: Matt Turner <mattst88@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by: Helge Deller <deller@gmx.de>
Matt Turner [Thu, 21 May 2026 05:56:45 +0000 (01:56 -0400)]
linux-user/hppa: add coredump support
Add HAVE_ELF_CORE_DUMP, target_elf_gregset_t (80 entries matching
arch/parisc/include/uapi/asm/ptrace.h), and elf_core_copy_regs().
The struct layout matches the kernel's struct user_regs_struct:
gr[0..31] at indices [0..31] (PSW in gr[0])
sr[0..7] at indices [32..39]
iaoq[0..1] at indices [40..41] (instruction address queue)
iasq[0..1] at indices [42..43]
sar at index [44] (shift amount / CR11)
iir at index [45] (interrupt instruction register)
isr at index [46] (interrupt space register)
ior at index [47] (interrupt offset register)
ipsw at index [48] (interrupt PSW / CR22)
cr0 at index [49] (recovery counter)
cr24_31[8] at indices [50..57]
cr8_15[6] at indices [58..63]
pad[16] at indices [64..79]
elf_core_copy_regs() saves GRs, IAOQ (front/back), and SAR.
* tag 'pull-fpu-20260522' of https://gitlab.com/rth7680/qemu: (30 commits)
fpu: Export floatN_minmax
fpu: Fix NaN encoding for E4M3 in parts64_uncanon
fpu: Introduce float_status.e4m3_nan_is_snan
fpu: Reorg float_status
fpu: Add accessors for rebias_{underflow,overflow}
fpu: Use get_float_default_nan_pattern in partsN_default_nan
fpu: Use get_default_nan_mode everywhere
fpu: Use {get,set}_flush_inputs_to_zero everywhere
fpu: Use accessors for ftz_before_rounding
fpu: Use {get,set}_flush_to_zero everywhere
fpu: Use accessors for tininess_before_rounding
fpu: Use get_float_infzeronan_rule in partsN_pick_nan_muladd
fpu: Use get_float_3nan_prop_rule in partsN_pick_nan_muladd
fpu: Use get_float_2nan_prop_rule in partsN_pick_nan
fpu: Use get_floatx80_behaviour everywhere
fpu: Use of {get,set}_floatx80_rounding_precision everywhere
fpu: Use {get,set}_float_rounding_mode everywhere
fpu: Introduce FloatSNaNRule
fpu: Introduce frac_msb_is_snan
target/alpha: Use FloatExceptionFlags
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Sun, 24 May 2026 11:44:52 +0000 (07:44 -0400)]
Merge tag 'pull-riscv-to-apply-20260522' of https://github.com/alistair23/qemu into staging
RISC-V PR for 11.1.
* Remove spike as default machine
* Deprecate the shakti_c machine
* Set MISA.[C|X] based on the selected extensions
* Update Maintainers for OpenSBI Firmware
* Update OpenSBI to v1.8.1
* Avoid RISCVCPU copy in PMU FDT setup
* A collection of specification compliance improvements
* Fix Svnapot 64KB pages
* Handle source overlap of vector widening reduction instructions
* Check interrupt in SiFive UART after txctrl register is written
* Fix medeleg[11] read-only zero bit for M-mode ECALL
* Fix tail handling for vmv.s.x and vfmv.s.f
* Update the local AIA interrupt mask
* Add KVM support for Zicbop and BFloat16 extensions
* Fix the IOMMU FSC SV32 capability check
* Avoid caching PCI device IDs in the IOMMU
* Implement Microchip mpfs ioscb PLLs and sysreg clock dividers
* Remove the internal CPU riscv_cpu_* arrays
* Fix IOCOUNTINH.CY toggle detection
* Fix the read of pmpaddr(0-63) CSRs
* Make hpmcounterh return the upper 32-bits
* Minor fixes and enhancements of RISC-V AIA devices
* Re-process IOMMU command queue after clearing CMD_ILL
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEaukCtqfKh31tZZKWr3yVEwxTgBMFAmoPnQkACgkQr3yVEwxT
# gBMudxAAvN8XD1zauMzk62tkXCmVA5fjqtTqu4Ytp8Pe3P7ZX9FZP6Alcw+G+zEd
# QQdIeHTzxzs77LO5VLKlLS807W5by9eMQDPOWvCRk2rQWJfgbxYq//dJNOPpJfR1
# ptDsvnxonfn8lh34Bm7nI+UaznRVSr3mSts8LN5R9GANLHRPYbJbtSRb2qSGBPzP
# ynNvuD0tmt9gXf+j9O9qr5DkoRoiZdoRTGdQ9a/eWlxP/eNvPzq0c74ToPpz3Obv
# 6z/ICImKZGL36W8B73FbGy30EySihdPTcLSQHqsUZ+mYtj+6WGtIbIoZkaugnfml
# M8DuukT6sO8GdZy7cFnxhThsnZ+HEylzpjHHWYJlvY9uUniM0wrCavCc0lvUm71A
# Mi0yASlmv6kXotxtmz+UZF6/h7vTJHXvEo/g9cwshSVjxYDhHf8GtIYVegLTTeoP
# z1UfpdepH6fe9E8cf6DUSwr1syODSf0qjiKVMVMxb/OMEk3qEB0uwbG+X1Ecs9s1
# SQo6cp5TdiSjzP87MyMDeTeaS6FQrkVEkXXgcpFf1W/R0zRuj/JW89sGCJvS7Tqk
# +bH4pNnzXTBNxuGrb3zZSC0yWdroSiqyT+9g/JlQMY9tBvnoY8p7Ck7g07nLhVSf
# Cj4C0SXRMSj8eHn2+pDqjZn1RUfG2mRAD+8yYWqZ2GvU2X/yhx8=
# =SSwl
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 21 May 2026 20:02:17 EDT
# gpg: using RSA key 6AE902B6A7CA877D6D659296AF7C95130C538013
# gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6AE9 02B6 A7CA 877D 6D65 9296 AF7C 9513 0C53 8013
* tag 'pull-riscv-to-apply-20260522' of https://github.com/alistair23/qemu: (48 commits)
hw/riscv: riscv-iommu: Re-process command queue after clearing CMD_ILL
hw/intc: riscv_aplic: add trace events of APLIC read/write function
hw/intc: riscv_imsic: Add reset API to IMSIC
hw/intc: riscv_aplic: Add reset API to APLIC
hw/intc: riscv_aplic: Fix level trigger IRQ in direct delivery mode
target/riscv: Make hpmcounterh return the upper 32-bits
hw/riscv/virt-acpi-build: Fix off-by-one error in RIMT ID mapping
target/riscv/csr.c: fix read of pmpaddr(0-63) CSRs
hw/riscv/riscv-iommu: Fix IOCOUNTINH.CY toggle detection
target/riscv/cpu: remove riscv_cpu_* arrays
target/riscv/tcg: use isa_edata_arr[] to create user props
target/riscv: do not set defaults in cpu prop callback
target/riscv/tcg: use cfg_offset as cpu_set_multi_ext cb opaque
target/riscv/tcg: use isa_edata_arr[] to enable max exts
target/riscv/kvm: use isa_edata_arr[] for unavailable props
target/riscv/tcg: use isa_edata_arr[] in riscv_cpu_update_misa_x()
target/riscv: remove riscv_cpu_named_features[]
target/riscv/cpu.c: remove riscv_cpu_enable_named_feat()
target/riscv/tcg: use only isa_edata_arr[] in cpu_cfg_ext_get_name()
target/riscv/tcg: treat all exts equally in cpu_disable_priv_spec_isa_exts
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Sun, 24 May 2026 11:44:37 +0000 (07:44 -0400)]
Merge tag 'misc-next-pull-request' of https://gitlab.com/berrange/qemu into staging
Misc patches for iotests, qom, crypt & io
* Fix client side anoymous TLS credentials
* Fix return value semantics for qio_channel_flush
* Add ID validation of internal QOM constructor
* Fix ability to create internal QOM objects
without a parent
* Merge user creatable object constructor into
main QOM file
* Print reason for skipping I/O tests
* Remove redundant meson suits for I/O tests
* Add optional suites for many block drivers I/O tests
* Run I/O tests for 10 block drivers in GitLab CI
* Fix sudo check for LUKS I/O test
* Mark I/O test 151, 181, 185, 308 as flaky
* tag 'misc-next-pull-request' of https://gitlab.com/berrange/qemu: (29 commits)
qom: drop user_creatable_add_type method
qom: allow object_new_with_prop* to trigger module loading
qom: fix ability to create objects without a parent
qom: add object_new_with_props_from_qdict
qom: move object_set_prop_keyval into object.c
qom: have object_set_props_keyval return bool
qom: shorten name of object_set_properties_from_keyval
qom: make errp last param in methods taking va_list
qom: validate ID format when creating objects
hw/vfio-user: use a valid object ID for iothread
qom: add trace events for object/property lifecycle
gitlab: remove I/O tests from build-tcg-disabled job
gitlab: add jobs for thorough block tests
iotests: mark 151, 181, 185 & 308 as flaky tests
iotests: fix check for sudo access in LUKS I/O test
iotests: validate dmsetup result in test 128
iotests: use 'driver' as collective term for either format or protocol
iotests: add nbd and luks to the I/O test suites
docs/devel/testing: expand documentation for 'make check-block'
iotests: add a meson suite / make target per block I/O tests format
...
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Amit Machhiwal [Mon, 18 May 2026 17:25:15 +0000 (22:55 +0530)]
target/ppc/kvm: Fix const violation when trimming CPU alias suffix
GCC 16 tightens diagnostics around const correctness and now correctly
rejects attempts to modify strings referenced through const-qualified
pointers. In kvm_ppc_register_host_cpu_type(), ppc_cpu_aliases[i].model
is defined as const char *, but the code was using strstr() on it and
then modifying the returned pointer in-place to strip
POWERPC_CPU_TYPE_SUFFIX.
This results in a write through a pointer derived from const data,
triggering a build failure with GCC 16:
error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
suffix = strstr(ppc_cpu_aliases[i].model, POWERPC_CPU_TYPE_SUFFIX);
^
Fix this by changing suffix to 'const gchar *' and using g_strstr_len()
to locate the suffix, then allocating a new string with g_strndup() (to
copy only the prefix) or g_strdup() (to copy the entire name if no
suffix exists). This maintains const correctness throughout while
preserving the original functionality.
Shivang Upadhyay [Mon, 11 May 2026 09:50:55 +0000 (15:20 +0530)]
ppc/spapr: Skip system reset for quiesced CPUs
During DLPAR CPU hotplug, newly added CPUs start in RTAS stopped state
(quiesced). If a kexec crash occurs before the guest starts these CPUs
via start-cpu RTAS call, H_SIGNAL_SYS_RESET_ALL_OTHERS will reset them
anyway, causing the kdump kernel to hang:
[ 5.519483][ T1] Processor 0 is stuck.
[ 11.089481][ T1] Processor 1 is stuck.
The hypervisor should only reset CPUs that the guest has started. The
cpu->env.quiesced flag tracks RTAS stopped state - CPUs in this state
are already inactive and should not be reset.
Skip system reset for quiesced CPUs to prevent kdump hangs during CPU
hotplug operations.
Cc: Sourabh Jain <sourabhjain@linux.ibm.com> Cc: Harsh Prateek Bora <harshpb@linux.ibm.com> Cc: Mahesh J Salgaonkar <mahesh@linux.ibm.com> Reported-by: Anushree Mathur <anushree.mathur@linux.vnet.ibm.com> Suggested-by: Vishal Chourasia <vishalc@linux.ibm.com> Reviewed-by: Vishal Chourasia <vishalc@linux.ibm.com> Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com> Link: https://lore.kernel.org/qemu-devel/20260511095055.82495-1-shivangu@linux.ibm.com
[harshpb: expanded comment to elobarate more on the rationale] Signed-off-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
projects / thirdparty / qemu.git / log
