qemu/qemu.git, branch stable-11.0

Update version for 11.0.2 release

2026-06-25T11:08:38+00:00

Signed-off-by: Michael Tokarev

linux-user: Fix AT_PHDR when program headers are relocated into their own segment

2026-06-24T13:34:52+00:00

When a binary is patched or relocated such that the program header table is moved into a separate PT_LOAD segment (rather than sitting at the start of the first loadable segment), QEMU's AT_PHDR auxv entry becomes incorrect. The loader was computing AT_PHDR as load_addr + e_phoff, which assumes the headers are mapped 1:1 from file offset 0. This breaks when the headers are elsewhere. The Linux kernel instead locates the PT_LOAD segment that contains e_phoff, then computes the in-memory address as p_vaddr + (e_phoff - p_offset). This correctly handles relocated headers. Fix by: 1. Add phdr_addr field to image_info to cache the resolved address. 2. Initialize to load_addr + e_phoff (fallback for headers outside any PT_LOAD). 3. In the PT_LOAD mapping loop, detect if the segment contains e_phoff and override with the segment-relative address. 4. Use info->phdr_addr for AT_PHDR instead of the incorrect formula. Signed-off-by: Akshit Yadav Reviewed-by: Helge Deller (cherry picked from commit 156e536a7b9700018aaa2437072c14e3376340a7) Signed-off-by: Michael Tokarev

hw/pci: Replace assert with bounds check and return

2026-06-24T13:34:52+00:00

As reported in https://gitlab.com/qemu-project/qemu/-/work_items/3334, callers of 'pci_host_config_{read,write}_common' can pass length as 8, causing an assert failure The original issue with pnv_phb3 triggering the assert was fixed in a previous commit Instead of asserting on invalid length, check if the length is valid (<=4), otherwise return (with the failure error code in read) Reported-by: Zexiang Zhang Signed-off-by: Aditya Gupta Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-Id: <20260326190438.734239-3-adityag@linux.ibm.com> (cherry picked from commit c7209c56718107fefd5deae140a450954d31ff2b) Signed-off-by: Michael Tokarev

ppc/pnv_phb3: Error out on invalid config access

2026-06-24T13:34:52+00:00

PHB in Power8 supports 8 byte registers, and hence the ops structure allows accessing of 8 bytes in 'pnv_phb3_reg_ops' Both 'pnv_phb3_reg_read' & 'pnv_phb3_reg_write' pass the arguments as is to 'pnv_phb3_config_{read,write}', if offset is PHB_CONFIG_DATA. This when called with size as 8, causes following assert failure in 'pci_host_config_read_common' & 'pci_host_config_write_common': assert(len <= 4); Validate that size is <=4, before jumping to pci_host_config_{read,write}_common Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3334 Reported-by: Zexiang Zhang Fixes: 9ae1329ee2fe ("ppc/pnv: Add models for POWER8 PHB3 PCIe Host bridge") Signed-off-by: Aditya Gupta Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Message-Id: <20260326190438.734239-2-adityag@linux.ibm.com> (cherry picked from commit 218109781209f9d77242b2cdf743acac8bc3b893) Signed-off-by: Michael Tokarev

linux-user/xtensa: fix unlock of uninitialized frame pointer on sigreturn

2026-06-24T13:34:52+00:00

If lock_user_struct fails, frame is uninitialized but the badframe label unconditionally calls unlock_user_struct on it. Handle the lock failure inline so badframe is only reached with a valid lock. Signed-off-by: Matt Turner Cc: qemu-stable@nongnu.org Reviewed-by: Helge Deller Signed-off-by: Helge Deller (cherry picked from commit 54e08dbe8f2aeca57e3b1a5eab09a9fec88c1c67) Signed-off-by: Michael Tokarev

linux-user/xtensa: save/restore FP registers across signal delivery

2026-06-24T13:34:52+00:00

Add support for saving and restoring f0-f15 across signal delivery. The target_xtensa_xtregs_fp struct carries 32-bit f-regs for cores with XTENSA_OPTION_FP_COPROCESSOR; target_xtensa_xtregs_dfp carries 64-bit f-regs for cores with XTENSA_OPTION_DFP_COPROCESSOR. Lock the xtregs region via lock_user before reading on sigreturn, since sc_xtregs is a user-space pointer that may lie outside the locked sigframe. Signed-off-by: Matt Turner Reviewed-by: Richard Henderson Signed-off-by: Helge Deller (cherry picked from commit 6858e3a71cc41510937bec0950eb4e42e33ba5f2) Signed-off-by: Michael Tokarev

target/xtensa: add cpu_set_fcr/fsr helpers to sync fp_status

2026-06-24T13:34:52+00:00

Factor FCR→fp_status and FSR→fp_status synchronisation out of the wur_fpu{2k,}_fcr/wur_fpu_fsr helpers into cpu_set_fcr(), cpu_set_fsr(), and cpu_get_fsr(). Signal delivery code needs to restore the FP rounding mode and exception flags without duplicating the flag-mapping tables. cpu_set_fcr() applies the union mask 0xfffff07f (superset of the wur_fpu_fcr mask 0x0000007f and the wur_fpu2k_fcr mask 0xfffff07f) so that FCR bits valid only on fpu2k configs are preserved while MBZ bits 7-11 are always cleared. Signed-off-by: Matt Turner Reviewed-by: Richard Henderson Signed-off-by: Helge Deller (cherry picked from commit 7e859bacea09a626c239f14ab9c01f13d5225723) Signed-off-by: Michael Tokarev

target/arm/hvf: Stop pre-allocating cpreg_vmstate arrays

2026-06-24T13:34:52+00:00

Commit ab2ddc7b66 ("target/arm/machine: Use VMSTATE_VARRAY_INT32_ALLOC for cpreg arrays") moved cpreg_vmstate_indexes / cpreg_vmstate_values to be allocated by VMSTATE_VARRAY_INT32_ALLOC and added an assertion in cpu_pre_load() that they are NULL on entry. The same commit dropped the redundant g_renew()/array_len assignments from the kvm, whpx and helper.c cpu init paths, but the hvf cpu init path still pre-allocates them. The result is that loading a snapshot or migration stream into an HVF guest immediately aborts: ERROR:target/arm/machine.c:1043:cpu_pre_load: assertion failed: (!cpu->cpreg_vmstate_indexes) Drop the leftover cpreg_vmstate_indexes / cpreg_vmstate_values allocations and the cpreg_vmstate_array_len assignment from hvf_arch_init_vcpu(), matching what was already done for the other arm accelerators. Signed-off-by: Scott J. Goldman Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Peter Maydell (cherry picked from commit 06fd39e426bbd3a68e50fc847892e7448174ce2f) Signed-off-by: Michael Tokarev

ui/sdl2: Set GL ES profile before creating initial GL context

2026-06-24T13:34:35+00:00

When the user selects GLES via '-display sdl,gl=es', we need to set SDL_GL_CONTEXT_PROFILE_MASK to SDL_GL_CONTEXT_PROFILE_ES before calling SDL_GL_CreateContext(). This ensures SDL_GL_LoadLibrary() loads the correct GLES driver instead of the desktop OpenGL driver. Fix the below issue: qemu-system-aarch64: /usr/src/debug/libepoxy /1.5.10/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed. sdl2_gl_create_context() already sets the profile mask correctly for ES mode, but the initial context created in sdl2_window_create() is missing the same treatment. Fixes:da3f7a3ab9ea0091955b58f8909dfcee01f4043e ("ui/sdl: try to instantiate the matching opengl renderer") Signed-off-by: ryan.zhang@nxp.com Reviewed-by: Marc-André Lureau Message-ID: (cherry picked from commit 490a3e1867f025c68fa13db766b5c8da16c6eca4) Signed-off-by: Michael Tokarev

ui/sdl2: Explicitly specify EGL platform

2026-06-24T07:36:22+00:00

Mesa's eglGetDisplay() chooses the native EGL platform from EGL_PLATFORM, limited autodetection, or the build-time default. If that selects Wayland while SDL is using the X11 video backend, Mesa can treat the X11 Display pointer as a wl_display and crash during eglInitialize(). Probe EGL with the X11 platform explicitly before enabling SDL_HINT_VIDEO_X11_FORCE_EGL. Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/3540 Signed-off-by: Akihiko Odaki Reviewed-by: Marc-André Lureau Message-ID: <20260611-sdl-v1-1-93d4a51684bb@rsg.ci.i.u-tokyo.ac.jp> (cherry picked from commit 6157908503f9a5a14d17a8ecf8cc3308107e1458) Signed-off-by: Michael Tokarev