* [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
@ 2026-05-28 20:26 Quan.Sun
2026-05-29 12:42 ` Mathieu Dubois-Briand
2026-06-02 16:57 ` Ross Burton
0 siblings, 2 replies; 28+ messages in thread
From: Quan.Sun @ 2026-05-28 20:26 UTC (permalink / raw)
To: openembedded-core
From: Quan Sun <Quan.Sun@windriver.com>
Upgrade QEMU to version 11.0.0.
Main changes:
- Add python3-qemu-qmp recipe (0.0.6) as a separate package. The QMP
Python library was removed from the QEMU source tree in 11.0.0 and
split into its own upstream project. This is needed by
qemu-system-native for testimage integration.
Add an entry for this recipe in maintainers.inc.
- QEMU 11.0.0 has officially dropped all support for 32-bit host systems.
This includes the ability to build the system emulator (softmmu) on
any 32-bit host architecture. Add COMPATIBLE_HOST for class-target and
class-nativesdk to restrict builds to 64-bit architectures. Fix SDK
build failure when SDKMACHINE is 32-bit.
Note: QEMU 11.0.0 still supports emulating 32-bit guest architectures
(such as qemu-system-i386 or qemu-system-arm) as long as they are
running on a 64-bit host.
- qemu-targets.inc: skip linux-user targets when HOST_ARCH is not in the
set of architectures supported by QEMU 11.0.0's linux-user mode
(64-bit only: aarch64, loongarch64, mips64, ppc64, riscv64, s390x,
sparc64, x86_64).
- Add --cpu=${TUNE_ARCH} to EXTRA_OECONF for class-target, and add
--cpu=${SDK_ARCH} to nativesdk configure options to fix build
failure. QEMU 11's configure script falls back to 'uname -m' (x86_64)
when it cannot detect the host CPU.
- Add 0012-meson-fix-close_range-detection-on-older-glibc.patch:
the meson has_function('close_range') check succeeds at link time on
hosts with kernel >= 5.9 even when glibc < 2.34 does not declare the
function, causing implicit declaration errors. Add a prefix include
so the check only succeeds when the header declares close_range().
- Add 0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch:
on build hosts with kernel headers < 6.0, vhost-scsi.c fails to
compile due to missing struct vhost_vring_worker/vhost_worker_state.
Include QEMU's bundled standard-headers before the system header,
matching the pattern already used in hw/virtio/vhost-backend.c.
- Drop fix-strerrorname_np.patch (fixed upstream).
Drop 0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch
(fixed upstream).
Drop 0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch
(fixed upstream).
AI-Generated: kiro-cli
Signed-off-by: Quan Sun <Quan.Sun@windriver.com>
---
meta/conf/distro/include/maintainers.inc | 1 +
.../nativesdk-packagegroup-sdk-host.bb | 3 +-
.../qemu/nativesdk-qemu-helper_1.0.bb | 2 +
.../qemu/python3-qemu-qmp_0.0.6.bb | 28 ++
...native_10.2.0.bb => qemu-native_11.0.0.bb} | 1 -
...10.2.0.bb => qemu-system-native_11.0.0.bb} | 7 +-
meta/recipes-devtools/qemu/qemu-targets.inc | 4 +
meta/recipes-devtools/qemu/qemu.inc | 26 +-
...tlb_to_section-for-different-Address.patch | 274 ------------------
...load.c-Correction-to-HWCAP2-accessor.patch | 42 ---
...n-environment-space-to-boot-loader-q.patch | 8 +-
.../0002-apic-fixup-fallthrough-to-PIC.patch | 6 +-
...mu-Do-not-include-file-if-not-exists.patch | 6 +-
...er-space-mmap-tweaks-to-address-musl.patch | 24 +-
.../qemu/0006-qemu-Determinism-fixes.patch | 4 +-
...d-use-relative-path-to-refer-to-file.patch | 6 +-
...and-MAP_SHARED_VALIDATE-on-needed-li.patch | 2 +-
...gure-lookup-meson-exutable-from-PATH.patch | 10 +-
...and-the-python-venv-aren-t-used-for-.patch | 10 +-
...close_range-detection-on-older-glibc.patch | 36 +++
| 35 +++
.../qemu/qemu/fix-strerrorname_np.patch | 35 ---
.../qemu/{qemu_10.2.0.bb => qemu_11.0.0.bb} | 0
23 files changed, 157 insertions(+), 413 deletions(-)
create mode 100644 meta/recipes-devtools/qemu/python3-qemu-qmp_0.0.6.bb
rename meta/recipes-devtools/qemu/{qemu-native_10.2.0.bb => qemu-native_11.0.0.bb} (99%)
rename meta/recipes-devtools/qemu/{qemu-system-native_10.2.0.bb => qemu-system-native_11.0.0.bb} (85%)
delete mode 100644 meta/recipes-devtools/qemu/qemu/0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch
delete mode 100644 meta/recipes-devtools/qemu/qemu/0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch
create mode 100644 meta/recipes-devtools/qemu/qemu/0012-meson-fix-close_range-detection-on-older-glibc.patch
create mode 100644 meta/recipes-devtools/qemu/qemu/0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch
delete mode 100644 meta/recipes-devtools/qemu/qemu/fix-strerrorname_np.patch
rename meta/recipes-devtools/qemu/{qemu_10.2.0.bb => qemu_11.0.0.bb} (100%)
diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
index af4ea1b14f..e6488d929c 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -706,6 +706,7 @@ RECIPE_MAINTAINER:pn-python3-pytest = "Trevor Gamblin <tgamblin@baylibre.com>"
RECIPE_MAINTAINER:pn-python3-pytest-subtests = "Tim Orling <tim.orling@konsulko.com>"
RECIPE_MAINTAINER:pn-python3-pytz = "Tim Orling <tim.orling@konsulko.com>"
RECIPE_MAINTAINER:pn-python3-pyyaml = "Tim Orling <tim.orling@konsulko.com>"
+RECIPE_MAINTAINER:pn-python3-qemu-qmp = "Richard Purdie <richard.purdie@linuxfoundation.org>"
RECIPE_MAINTAINER:pn-python3-rdflib = "Wang Mingyu <wangmy@fujitsu.com>"
RECIPE_MAINTAINER:pn-python3-referencing = "Trevor Gamblin <tgamblin@baylibre.com>"
RECIPE_MAINTAINER:pn-python3-requests = "Tim Orling <tim.orling@konsulko.com>"
diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index c1d3c25060..51e48f250b 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -13,8 +13,7 @@ PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"
# build some recent linux kernels (5.14+) for arm
RDEPENDS:${PN} = "\
nativesdk-pkgconfig \
- nativesdk-qemu \
- nativesdk-qemu-helper \
+ ${@'nativesdk-qemu nativesdk-qemu-helper' if d.getVar('SDK_ARCH') in ['x86_64', 'aarch64', 'ppc64', 'ppc64le', 'riscv64', 'loongarch64', 'mips64', 's390x', 'sparc64'] else ''} \
nativesdk-pseudo \
nativesdk-unfs3 \
nativesdk-opkg \
diff --git a/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb b/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
index 35735c1e15..60fb635600 100644
--- a/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
+++ b/meta/recipes-devtools/qemu/nativesdk-qemu-helper_1.0.bb
@@ -1,5 +1,7 @@
SUMMARY = "Qemu helper scripts"
LICENSE = "GPL-2.0-only"
+# QEMU 11.0.0+ requires a 64-bit host architecture
+COMPATIBLE_HOST = "(aarch64|x86_64|ppc64|riscv64|loongarch64|mips64|s390x|sparc64).*-linux"
RDEPENDS:${PN} = "nativesdk-qemu nativesdk-unfs3 nativesdk-pseudo \
nativesdk-python3-shell nativesdk-python3-fcntl nativesdk-python3-logging \
"
diff --git a/meta/recipes-devtools/qemu/python3-qemu-qmp_0.0.6.bb b/meta/recipes-devtools/qemu/python3-qemu-qmp_0.0.6.bb
new file mode 100644
index 0000000000..4b3bbe6670
--- /dev/null
+++ b/meta/recipes-devtools/qemu/python3-qemu-qmp_0.0.6.bb
@@ -0,0 +1,28 @@
+SUMMARY = "QEMU Monitor Protocol Python library"
+DESCRIPTION = "An asyncio library for communicating with QEMU Monitor Protocol (QMP). \
+This library was split out of the QEMU source tree to provide a reference QMP \
+implementation usable both within and outside of the QEMU source tree."
+HOMEPAGE = "https://gitlab.com/qemu-project/python-qemu-qmp"
+LICENSE = "LGPL-2.0-only & GPL-2.0-only"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=4cf66a4984120007c9881cc871cf49db"
+
+inherit pypi python_setuptools_build_meta
+
+PYPI_PACKAGE = "qemu_qmp"
+
+SRC_URI[sha256sum] = "a3c25d871fab549122b2340810de1f99481002c942a2132476b062aacdbf6e92"
+
+DEPENDS += "python3-setuptools-scm-native"
+
+RDEPENDS:${PN} += "python3-core python3-asyncio"
+
+# Install to the custom path expected by oeqa/utils/qemurunner.py
+# which imports "qmp.legacy" from ${libdir}/qemu-python/
+do_install:append:class-native() {
+ install -d ${D}${libdir}/qemu-python/qmp/
+ cp -R --no-dereference --preserve=mode,links ${S}/qemu/qmp/* ${D}${libdir}/qemu-python/qmp/
+}
+
+FILES:${PN}:append:class-native = " ${libdir}/qemu-python"
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/qemu/qemu-native_10.2.0.bb b/meta/recipes-devtools/qemu/qemu-native_11.0.0.bb
similarity index 99%
rename from meta/recipes-devtools/qemu/qemu-native_10.2.0.bb
rename to meta/recipes-devtools/qemu/qemu-native_11.0.0.bb
index 26fa84c180..a77953529b 100644
--- a/meta/recipes-devtools/qemu/qemu-native_10.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-native_11.0.0.bb
@@ -7,4 +7,3 @@ require qemu-native.inc
EXTRA_OECONF:append = " --target-list=${@get_qemu_usermode_target_list(d)} --disable-tools --disable-install-blobs --disable-guest-agent"
PACKAGECONFIG ??= "pie"
-
diff --git a/meta/recipes-devtools/qemu/qemu-system-native_10.2.0.bb b/meta/recipes-devtools/qemu/qemu-system-native_11.0.0.bb
similarity index 85%
rename from meta/recipes-devtools/qemu/qemu-system-native_10.2.0.bb
rename to meta/recipes-devtools/qemu/qemu-system-native_11.0.0.bb
index 2e4f7328ad..7947499c5f 100644
--- a/meta/recipes-devtools/qemu/qemu-system-native_10.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-system-native_11.0.0.bb
@@ -5,7 +5,7 @@ require qemu-native.inc
# As some of the files installed by qemu-native and qemu-system-native
# are the same, we depend on qemu-native to get the full installation set
# and avoid file clashes
-DEPENDS += "glib-2.0-native zlib-native pixman-native qemu-native"
+DEPENDS += "glib-2.0-native zlib-native pixman-native qemu-native python3-qemu-qmp-native"
EXTRA_OECONF:append = " --target-list=${@get_qemu_system_target_list(d)}"
@@ -25,9 +25,4 @@ do_install:append() {
rm -rf ${D}${datadir}/qemu/dtb
rm -rf ${D}${datadir}/icons/
rm -rf ${D}${includedir}/qemu-plugin.h
-
- # Install qmp.py to be used with testimage
- install -d ${D}${libdir}/qemu-python/qmp/
- install -D ${S}/python/qemu/qmp/* ${D}${libdir}/qemu-python/qmp/
}
-
diff --git a/meta/recipes-devtools/qemu/qemu-targets.inc b/meta/recipes-devtools/qemu/qemu-targets.inc
index 50e5eb6796..937ef1a911 100644
--- a/meta/recipes-devtools/qemu/qemu-targets.inc
+++ b/meta/recipes-devtools/qemu/qemu-targets.inc
@@ -25,6 +25,10 @@ def get_qemu_target_list(d):
archs.remove(arch)
if 'linux' not in tos:
return softmmuonly + ''.join([arch + "-softmmu" + "," for arch in archs]).rstrip(',')
+ # QEMU 11.0.0+ only supports linux-user on 64-bit host architectures
+ linux_user_hosts = ['aarch64', 'loongarch64', 'mips64', 'ppc64', 'riscv64', 's390x', 'sparc64', 'x86_64']
+ if tarch not in linux_user_hosts:
+ return softmmuonly + ''.join([arch + "-softmmu" + "," for arch in archs]).rstrip(',')
return softmmuonly + linuxuseronly + ''.join([arch + "-linux-user" + "," + arch + "-softmmu" + "," for arch in archs]).rstrip(',')
def get_qemu_usermode_target_list(d):
diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc
index 5f30416a48..f61f43de4b 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -4,6 +4,7 @@ machine's processor through dynamic binary translation and provides a set \
of different hardware and device models for the machine, enabling it to run \
a variety of guest operating systems"
HOMEPAGE = "http://qemu.org"
+BUGTRACKER = "https://gitlab.com/qemu-project/qemu/-/issues"
LICENSE = "GPL-2.0-only & LGPL-2.1-only"
DEPENDS += "bison-native meson-native ninja-native"
@@ -22,7 +23,6 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a3b50d8b88dcc0eb3d7d39b760b9e821 \
SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://powerpc_rom.bin \
file://run-ptest \
- file://fix-strerrorname_np.patch \
file://0001-qemu-Add-addition-environment-space-to-boot-loader-q.patch \
file://0002-apic-fixup-fallthrough-to-PIC.patch \
file://0004-qemu-Do-not-include-file-if-not-exists.patch \
@@ -32,8 +32,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0008-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch \
file://0010-configure-lookup-meson-exutable-from-PATH.patch \
file://0011-qemu-Ensure-pip-and-the-python-venv-aren-t-used-for-.patch \
- file://0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch \
- file://0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch \
+ file://0012-meson-fix-close_range-detection-on-older-glibc.patch \
+ file://0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch \
file://qemu-guest-agent.init \
file://qemu-guest-agent.udev \
"
@@ -41,7 +41,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
UPSTREAM_CHECK_URI = "https://www.qemu.org"
UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar"
-SRC_URI[sha256sum] = "9e30ad1b8b9f7b4463001582d1ab297f39cfccea5d08540c0ca6d6672785883a"
+SRC_URI[sha256sum] = "c04ca36012653f32d11c674d370cf52a710e7d3f18c2d8b63e4932052a4854d6"
CVE_STATUS[CVE-2007-0998] = "not-applicable-config: The VNC server can expose host files uder some circumstances. We don't enable it by default."
@@ -61,6 +61,10 @@ COMPATIBLE_HOST:mipsarchn32 = "null"
COMPATIBLE_HOST:mipsarchn64 = "null"
COMPATIBLE_HOST:riscv32 = "null"
+# QEMU 11.0.0+ requires a 64-bit host architecture for emulator builds
+COMPATIBLE_HOST:class-target = "(aarch64|x86_64|ppc64|riscv64|loongarch64|mips64|s390x|sparc64).*-linux"
+COMPATIBLE_HOST:class-nativesdk = "(aarch64|x86_64|ppc64|riscv64|loongarch64|mips64|s390x|sparc64).*-linux"
+
# Per https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03873.html
# upstream states qemu doesn't work without optimization
DEBUG_BUILD = "0"
@@ -75,7 +79,7 @@ do_install_ptest() {
find ${D}${PTEST_PATH}/tests -type f -name "*.[Sshcodp]" | xargs -i rm -rf {}
# Don't check the file genreated by configure
- sed -i -e "1s,#!/usr/bin/bash,#!${base_bindir}/bash," ${D}${PTEST_PATH}/tests/data/acpi/disassemle-aml.sh
+ sed -i -e "1s,#!/usr/bin/bash,#!${base_bindir}/bash," ${D}${PTEST_PATH}/tests/data/acpi/disassemble-aml.sh
# Strip the paths from the QEMU variable, we can use PATH
makfiles=$(find ${D}${PTEST_PATH} -name "*.mak")
@@ -119,19 +123,17 @@ EXTRA_OECONF = " \
${PACKAGECONFIG_CONFARGS} \
"
-EXTRA_OECONF:append:class-target = " --cross-prefix=${HOST_PREFIX}"
-EXTRA_OECONF:append:class-nativesdk = " --cross-prefix=${HOST_PREFIX}"
+EXTRA_OECONF:append:class-target = " --cross-prefix=${HOST_PREFIX} --cpu=${TUNE_ARCH}"
+EXTRA_OECONF:append:class-nativesdk = " --cross-prefix=${HOST_PREFIX} --cpu=${@d.getVar('SDK_ARCH').replace('i686', 'i386')}"
B = "${WORKDIR}/build"
#EXTRA_OECONF:append = " --python=${HOSTTOOLS_DIR}/python3"
do_configure:prepend:class-native() {
- # Append build host pkg-config paths for native target since the host may provide sdl
- BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config --variable pc_path pkg-config || echo "")
- if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
- export PKG_CONFIG_LIBDIR=$PKG_CONFIG_LIBDIR:$BHOST_PKGCONFIG_PATH
- fi
+ # Avoid leaking host pkg-config paths which may find incompatible
+ # old system libraries (e.g. glib-2.0, fixesproto, gtk+-3.0)
+ export PKG_CONFIG_PATH="${STAGING_LIBDIR_NATIVE}/pkgconfig:${STAGING_DATADIR_NATIVE}/pkgconfig"
}
do_configure() {
diff --git a/meta/recipes-devtools/qemu/qemu/0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch b/meta/recipes-devtools/qemu/qemu/0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch
deleted file mode 100644
index d19f872fc3..0000000000
--- a/meta/recipes-devtools/qemu/qemu/0001-accel-tcg-Fix-iotlb_to_section-for-different-Address.patch
+++ /dev/null
@@ -1,274 +0,0 @@
-From 858e6bb252e075e09cca6e78299151d3af0bf5fb Mon Sep 17 00:00:00 2001
-From: Quan Sun <Quan.Sun@windriver.com>
-Date: Tue, 28 Apr 2026 14:56:36 -0400
-Subject: [PATCH] accel/tcg: Fix iotlb_to_section() for different AddressSpace
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-'CPUTLBEntryFull.xlat_section' stores section_index in last 12 bits to
-find the correct section when CPU access the IO region over the IOTLB.
-However, section_index is only unique inside single AddressSpace. If
-address space translation is over IOMMUMemoryRegion, it could return
-section from other AddressSpace. 'iotlb_to_section()' API only finds the
-sections from CPU's AddressSpace so that it couldn't find section in
-other AddressSpace. Thus, using 'iotlb_to_section()' API will find the
-wrong section and QEMU will have wrong load/store access.
-
-To fix this bug of iotlb_to_section(), store complete MemoryRegionSection
-pointer in CPUTLBEntryFull to replace the section_index in xlat_section.
-Rename 'xlat_section' to 'xlat_offset' as we remove last 12 bits
-section_index inside. Also, since we directly use section pointer in the
-CPUTLBEntryFull (full->section), we can remove the unused functions:
-iotlb_to_section(), memory_region_section_get_iotlb().
-
-This bug occurs only when
-(1) IOMMUMemoryRegion is in the path of CPU access.
-(2) IOMMUMemoryRegion returns different target_as and the section is in
-the IO region.
-
-This patch incorporates prerequisite changes from upstream commit
-94c6e9cf0440 ("accel/tcg: Send the CPUTLBEntryFull struct into
-io_prepare()") needed for the fix to apply cleanly.
-
-Upstream-Status: Backport [https://gitlab.com/qemu-project/qemu/-/commit/854cd16e318eed12de2995014b28d9f374c64bf7]
-
-Signed-off-by: Jim Shu <jim.shu@sifive.com>
-Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
-Tested-by: Mark Burton <mburton@qti.qualcomm.com>
-Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
-Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
-Signed-off-by: Quan Sun <Quan.Sun@windriver.com>
----
- accel/tcg/cputlb.c | 32 +++++++++++++++-----------------
- include/accel/tcg/iommu.h | 15 ---------------
- include/exec/cputlb.h | 4 ++--
- include/hw/core/cpu.h | 17 +++++++++--------
- system/physmem.c | 25 -------------------------
- 5 files changed, 26 insertions(+), 67 deletions(-)
-
-diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
-index fd1606c85..fa0f4d8b3 100644
---- a/accel/tcg/cputlb.c
-+++ b/accel/tcg/cputlb.c
-@@ -1089,7 +1089,7 @@ void tlb_set_page_full(CPUState *cpu, int mmu_idx,
- }
- } else {
- /* I/O or ROMD */
-- iotlb = memory_region_section_get_iotlb(cpu, section) + xlat;
-+ iotlb = xlat;
- /*
- * Writes to romd devices must go through MMIO to enable write.
- * Reads to romd devices go through the ram_ptr found above,
-@@ -1140,10 +1140,9 @@ void tlb_set_page_full(CPUState *cpu, int mmu_idx,
- /*
- * When memory region is ram, iotlb contains a TARGET_PAGE_BITS
- * aligned ram_addr_t of the page base of the target RAM.
-- * Otherwise, iotlb contains
-- * - a physical section number in the lower TARGET_PAGE_BITS
-- * - the offset within section->mr of the page base (I/O, ROMD) with the
-- * TARGET_PAGE_BITS masked off.
-+ * Otherwise, iotlb contains a TARGET_PAGE_BITS aligned
-+ * offset within section->mr of the page base (I/O, ROMD)
-+ *
- * We subtract addr_page (which is page aligned and thus won't
- * disturb the low bits) to give an offset which can be added to the
- * (non-page-aligned) vaddr of the eventual memory access to get
-@@ -1153,7 +1152,8 @@ void tlb_set_page_full(CPUState *cpu, int mmu_idx,
- */
- desc->fulltlb[index] = *full;
- full = &desc->fulltlb[index];
-- full->xlat_section = iotlb - addr_page;
-+ full->xlat_offset = iotlb - addr_page;
-+ full->section = section;
- full->phys_addr = paddr_page;
-
- /* Now calculate the new entry */
-@@ -1269,14 +1269,14 @@ static inline void cpu_unaligned_access(CPUState *cpu, vaddr addr,
- }
-
- static MemoryRegionSection *
--io_prepare(hwaddr *out_offset, CPUState *cpu, hwaddr xlat,
-+io_prepare(hwaddr *out_offset, CPUState *cpu, CPUTLBEntryFull *full,
- MemTxAttrs attrs, vaddr addr, uintptr_t retaddr)
- {
- MemoryRegionSection *section;
- hwaddr mr_offset;
-
-- section = iotlb_to_section(cpu, xlat, attrs);
-- mr_offset = (xlat & TARGET_PAGE_MASK) + addr;
-+ section = full->section;
-+ mr_offset = full->xlat_offset + addr;
- cpu->mem_io_pc = retaddr;
- if (!cpu->neg.can_do_io) {
- cpu_io_recompile(cpu, retaddr);
-@@ -1335,7 +1335,7 @@ static bool victim_tlb_hit(CPUState *cpu, size_t mmu_idx, size_t index,
- static void notdirty_write(CPUState *cpu, vaddr mem_vaddr, unsigned size,
- CPUTLBEntryFull *full, uintptr_t retaddr)
- {
-- ram_addr_t ram_addr = mem_vaddr + full->xlat_section;
-+ ram_addr_t ram_addr = mem_vaddr + full->xlat_offset;
-
- trace_memory_notdirty_write_access(mem_vaddr, ram_addr, size);
-
-@@ -1592,9 +1592,7 @@ bool tlb_plugin_lookup(CPUState *cpu, vaddr addr, int mmu_idx,
-
- /* We must have an iotlb entry for MMIO */
- if (tlb_addr & TLB_MMIO) {
-- MemoryRegionSection *section =
-- iotlb_to_section(cpu, full->xlat_section & ~TARGET_PAGE_MASK,
-- full->attrs);
-+ MemoryRegionSection *section = full->section;
- data->is_io = true;
- data->mr = section->mr;
- } else {
-@@ -1980,7 +1978,7 @@ static uint64_t do_ld_mmio_beN(CPUState *cpu, CPUTLBEntryFull *full,
- tcg_debug_assert(size > 0 && size <= 8);
-
- attrs = full->attrs;
-- section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
-+ section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
- mr = section->mr;
-
- BQL_LOCK_GUARD();
-@@ -2001,7 +1999,7 @@ static Int128 do_ld16_mmio_beN(CPUState *cpu, CPUTLBEntryFull *full,
- tcg_debug_assert(size > 8 && size <= 16);
-
- attrs = full->attrs;
-- section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
-+ section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
- mr = section->mr;
-
- BQL_LOCK_GUARD();
-@@ -2521,7 +2519,7 @@ static uint64_t do_st_mmio_leN(CPUState *cpu, CPUTLBEntryFull *full,
- tcg_debug_assert(size > 0 && size <= 8);
-
- attrs = full->attrs;
-- section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
-+ section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
- mr = section->mr;
-
- BQL_LOCK_GUARD();
-@@ -2541,7 +2539,7 @@ static uint64_t do_st16_mmio_leN(CPUState *cpu, CPUTLBEntryFull *full,
- tcg_debug_assert(size > 8 && size <= 16);
-
- attrs = full->attrs;
-- section = io_prepare(&mr_offset, cpu, full->xlat_section, attrs, addr, ra);
-+ section = io_prepare(&mr_offset, cpu, full, attrs, addr, ra);
- mr = section->mr;
-
- BQL_LOCK_GUARD();
-diff --git a/include/accel/tcg/iommu.h b/include/accel/tcg/iommu.h
-index 90cfd6c0e..547f8ea0e 100644
---- a/include/accel/tcg/iommu.h
-+++ b/include/accel/tcg/iommu.h
-@@ -14,18 +14,6 @@
- #include "exec/hwaddr.h"
- #include "exec/memattrs.h"
-
--/**
-- * iotlb_to_section:
-- * @cpu: CPU performing the access
-- * @index: TCG CPU IOTLB entry
-- *
-- * Given a TCG CPU IOTLB entry, return the MemoryRegionSection that
-- * it refers to. @index will have been initially created and returned
-- * by memory_region_section_get_iotlb().
-- */
--MemoryRegionSection *iotlb_to_section(CPUState *cpu,
-- hwaddr index, MemTxAttrs attrs);
--
- MemoryRegionSection *address_space_translate_for_iotlb(CPUState *cpu,
- int asidx,
- hwaddr addr,
-@@ -34,8 +22,5 @@ MemoryRegionSection *address_space_translate_for_iotlb(CPUState *cpu,
- MemTxAttrs attrs,
- int *prot);
-
--hwaddr memory_region_section_get_iotlb(CPUState *cpu,
-- MemoryRegionSection *section);
--
- #endif
-
-diff --git a/include/exec/cputlb.h b/include/exec/cputlb.h
-index 9bec0e789..16f866990 100644
---- a/include/exec/cputlb.h
-+++ b/include/exec/cputlb.h
-@@ -43,8 +43,8 @@ void tlb_reset_dirty_range_all(ram_addr_t start, ram_addr_t length);
- * @full: the details of the tlb entry
- *
- * Add an entry to @cpu tlb index @mmu_idx. All of the fields of
-- * @full must be filled, except for xlat_section, and constitute
-- * the complete description of the translated page.
-+ * @full must be filled, except for xlat_offset & section, and
-+ * constitute the complete description of the translated page.
- *
- * This is generally called by the target tlb_fill function after
- * having performed a successful page table walk to find the physical
-diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
-index 961505177..a3db3f66f 100644
---- a/include/hw/core/cpu.h
-+++ b/include/hw/core/cpu.h
-@@ -214,15 +214,16 @@ typedef uint32_t MMUIdxMap;
- */
- struct CPUTLBEntryFull {
- /*
-- * @xlat_section contains:
-- * - in the lower TARGET_PAGE_BITS, a physical section number
-- * - with the lower TARGET_PAGE_BITS masked off, an offset which
-- * must be added to the virtual address to obtain:
-- * + the ram_addr_t of the target RAM (if the physical section
-- * number is PHYS_SECTION_NOTDIRTY or PHYS_SECTION_ROM)
-- * + the offset within the target MemoryRegion (otherwise)
-+ * @xlat_offset: TARGET_PAGE_BITS aligned offset which must be added to
-+ * the virtual address to obtain:
-+ * + the ram_addr_t of the target RAM (if the physical section
-+ * number is PHYS_SECTION_NOTDIRTY or PHYS_SECTION_ROM)
-+ * + the offset within the target MemoryRegion (otherwise)
- */
-- hwaddr xlat_section;
-+ hwaddr xlat_offset;
-+
-+ /* @section contains physical section. */
-+ MemoryRegionSection *section;
-
- /*
- * @phys_addr contains the physical address in the address space
-diff --git a/system/physmem.c b/system/physmem.c
-index c9869e404..a21e7ca64 100644
---- a/system/physmem.c
-+++ b/system/physmem.c
-@@ -748,31 +748,6 @@ translate_fail:
- return &d->map.sections[PHYS_SECTION_UNASSIGNED];
- }
-
--MemoryRegionSection *iotlb_to_section(CPUState *cpu,
-- hwaddr index, MemTxAttrs attrs)
--{
-- int asidx = cpu_asidx_from_attrs(cpu, attrs);
-- CPUAddressSpace *cpuas = &cpu->cpu_ases[asidx];
-- AddressSpaceDispatch *d = address_space_to_dispatch(cpuas->as);
-- int section_index = index & ~TARGET_PAGE_MASK;
-- MemoryRegionSection *ret;
--
-- assert(section_index < d->map.sections_nb);
-- ret = d->map.sections + section_index;
-- assert(ret->mr);
-- assert(ret->mr->ops);
--
-- return ret;
--}
--
--/* Called from RCU critical section */
--hwaddr memory_region_section_get_iotlb(CPUState *cpu,
-- MemoryRegionSection *section)
--{
-- AddressSpaceDispatch *d = flatview_to_dispatch(section->fv);
-- return section - d->map.sections;
--}
--
- #endif /* CONFIG_TCG */
-
- void cpu_address_space_init(CPUState *cpu, int asidx,
---
-2.43.0
diff --git a/meta/recipes-devtools/qemu/qemu/0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch b/meta/recipes-devtools/qemu/qemu/0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch
deleted file mode 100644
index 47d6f41385..0000000000
--- a/meta/recipes-devtools/qemu/qemu/0001-linux-user-elfload.c-Correction-to-HWCAP2-accessor.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From c333f9c4ee212297f3b9a8a6ef62396a63c48e61 Mon Sep 17 00:00:00 2001
-From: Jim MacArthur <jim.macarthur@linaro.org>
-Date: Tue, 6 Jan 2026 15:40:48 +0000
-Subject: [PATCH] linux-user/elfload.c: Correction to HWCAP2 accessor
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-get_elf_hwcap was used when get_elf_hwcap2 should have been.
-
-Cc: qemu-stable@nongnu.org
-Fixes: fcac98d0ba8b ("linux-user: Remove ELF_HWCAP2")
-Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3259
-Signed-off-by: Jim MacArthur <jim.macarthur@linaro.org>
-Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
-Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
-Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
-Message-ID: <20260106-fix-hwcap2-sve2-v1-1-1d70dff63370@linaro.org>
-
-Upstream-Status: Backport [https://gitlab.com/qemu-project/qemu/-/commit/c333f9c4ee212297f3b9a8a6ef62396a63c48e61]
-
-Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
----
- linux-user/elfload.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/linux-user/elfload.c b/linux-user/elfload.c
-index 0002d5be2f..35471c0c9a 100644
---- a/linux-user/elfload.c
-+++ b/linux-user/elfload.c
-@@ -708,7 +708,7 @@ static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
- NEW_AUX_ENT(AT_EXECFN, info->file_string);
-
- if (HAVE_ELF_HWCAP2) {
-- NEW_AUX_ENT(AT_HWCAP2, get_elf_hwcap(thread_cpu));
-+ NEW_AUX_ENT(AT_HWCAP2, get_elf_hwcap2(thread_cpu));
- }
- if (u_base_platform) {
- NEW_AUX_ENT(AT_BASE_PLATFORM, u_base_platform);
---
-2.34.1
-
diff --git a/meta/recipes-devtools/qemu/qemu/0001-qemu-Add-addition-environment-space-to-boot-loader-q.patch b/meta/recipes-devtools/qemu/qemu/0001-qemu-Add-addition-environment-space-to-boot-loader-q.patch
index bc8dace013..40b08cd247 100644
--- a/meta/recipes-devtools/qemu/qemu/0001-qemu-Add-addition-environment-space-to-boot-loader-q.patch
+++ b/meta/recipes-devtools/qemu/qemu/0001-qemu-Add-addition-environment-space-to-boot-loader-q.patch
@@ -1,10 +1,10 @@
-From f2d9bc614f7edf66412209aba78aa086e65dc75e Mon Sep 17 00:00:00 2001
+From a84184c98cf296954e0c757604e969b8565eb474 Mon Sep 17 00:00:00 2001
From: Jason Wessel <jason.wessel@windriver.com>
Date: Fri, 28 Mar 2014 17:42:43 +0800
Subject: [PATCH] qemu: Add addition environment space to boot loader
qemu-system-mips
-Upstream-Status: Inappropriate - OE uses deep paths
+Upstream-Status: Inappropriate [OE uses deep paths]
If you create a project with very long directory names like 128 characters
deep and use NFS, the kernel arguments will be truncated. The kernel will
@@ -18,10 +18,10 @@ Signed-off-by: Roy Li <rongqing.li@windriver.com>
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
-index cbdbb2105..62681fdae 100644
+index 812ff64d8..daf929943 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
-@@ -65,7 +65,7 @@
+@@ -66,7 +66,7 @@
#define ENVP_PADDR 0x2000
#define ENVP_VADDR cpu_mips_phys_to_kseg0(NULL, ENVP_PADDR)
#define ENVP_NB_ENTRIES 16
diff --git a/meta/recipes-devtools/qemu/qemu/0002-apic-fixup-fallthrough-to-PIC.patch b/meta/recipes-devtools/qemu/qemu/0002-apic-fixup-fallthrough-to-PIC.patch
index bfc85f4842..ad00f24482 100644
--- a/meta/recipes-devtools/qemu/qemu/0002-apic-fixup-fallthrough-to-PIC.patch
+++ b/meta/recipes-devtools/qemu/qemu/0002-apic-fixup-fallthrough-to-PIC.patch
@@ -1,4 +1,4 @@
-From 945af9ecc80653955cbdbb7d3e28dce61795b251 Mon Sep 17 00:00:00 2001
+From 0a688e763d91c2e0e11cbe960f405442a9f35417 Mon Sep 17 00:00:00 2001
From: Mark Asselstine <mark.asselstine@windriver.com>
Date: Tue, 26 Feb 2013 11:43:28 -0500
Subject: [PATCH] apic: fixup fallthrough to PIC
@@ -33,10 +33,10 @@ Signed-off-by: Kai Kang <kai.kang@windriver.com>
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
-index aad253a..212b01f 100644
+index 8766ed00b..581fc6deb 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
-@@ -740,7 +740,7 @@ int apic_accept_pic_intr(APICCommonState *s)
+@@ -741,7 +741,7 @@ int apic_accept_pic_intr(APICCommonState *s)
{
uint32_t lvt0;
diff --git a/meta/recipes-devtools/qemu/qemu/0004-qemu-Do-not-include-file-if-not-exists.patch b/meta/recipes-devtools/qemu/qemu/0004-qemu-Do-not-include-file-if-not-exists.patch
index 2e738abaa3..4b6ac54445 100644
--- a/meta/recipes-devtools/qemu/qemu/0004-qemu-Do-not-include-file-if-not-exists.patch
+++ b/meta/recipes-devtools/qemu/qemu/0004-qemu-Do-not-include-file-if-not-exists.patch
@@ -1,4 +1,4 @@
-From f8c1614b204c1d64af906dc70dbf4a1534eb6b38 Mon Sep 17 00:00:00 2001
+From b38315a5a6f9fc033c72bb94ff258bb4b1ac8dd3 Mon Sep 17 00:00:00 2001
From: Oleksiy Obitotskyy <oobitots@cisco.com>
Date: Wed, 25 Mar 2020 21:21:35 +0200
Subject: [PATCH] qemu: Do not include file if not exists
@@ -16,10 +16,10 @@ Signed-off-by: Sakib Sajal <sakib.sajal@windriver.com>
1 file changed, 2 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
-index c236b2834..2a3527a87 100644
+index f4b74ad35..3da51ea83 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
-@@ -119,7 +119,9 @@
+@@ -117,7 +117,9 @@
#include <linux/blkpg.h>
#include <netpacket/packet.h>
#include <linux/netlink.h>
diff --git a/meta/recipes-devtools/qemu/qemu/0005-qemu-Add-some-user-space-mmap-tweaks-to-address-musl.patch b/meta/recipes-devtools/qemu/qemu/0005-qemu-Add-some-user-space-mmap-tweaks-to-address-musl.patch
index ffbbb1ab32..59236999f9 100644
--- a/meta/recipes-devtools/qemu/qemu/0005-qemu-Add-some-user-space-mmap-tweaks-to-address-musl.patch
+++ b/meta/recipes-devtools/qemu/qemu/0005-qemu-Add-some-user-space-mmap-tweaks-to-address-musl.patch
@@ -1,4 +1,4 @@
-From 3621615790270449bf9c8a0777e8ef28eb762bf9 Mon Sep 17 00:00:00 2001
+From e4abb937ba5a6a476d31886e71e67006df22a664 Mon Sep 17 00:00:00 2001
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Fri, 8 Jan 2021 17:27:06 +0000
Subject: [PATCH] qemu: Add some user space mmap tweaks to address musl 32 bit
@@ -16,32 +16,24 @@ A better return value for the other cases of invalid addresses is EINVAL
rather than ENOMEM so adjust the other part of the test to this.
Upstream-Status: Submitted [https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg01355.html]
-Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
+Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
- linux-user/mmap.c | 10 +++++++---
- 1 file changed, 7 insertions(+), 3 deletions(-)
+ linux-user/mmap.c | 5 +++++
+ 1 file changed, 5 insertions(+)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
-index 002e1e668..912839dec 100644
+index b635b6a21..a5a617516 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
-@@ -1109,12 +1109,16 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
+@@ -1113,6 +1113,11 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
int prot;
void *host_addr;
-- if (!guest_range_valid_untagged(old_addr, old_size) ||
-- ((flags & MREMAP_FIXED) &&
+ if (!guest_range_valid_untagged(old_addr, old_size)) {
+ errno = EFAULT;
+ return -1;
+ }
-+
-+ if (((flags & MREMAP_FIXED) &&
++
+ if (((flags & MREMAP_FIXED) &&
!guest_range_valid_untagged(new_addr, new_size)) ||
((flags & MREMAP_MAYMOVE) == 0 &&
- !guest_range_valid_untagged(old_addr, new_size))) {
-- errno = ENOMEM;
-+ errno = EINVAL;
- return -1;
- }
-
diff --git a/meta/recipes-devtools/qemu/qemu/0006-qemu-Determinism-fixes.patch b/meta/recipes-devtools/qemu/qemu/0006-qemu-Determinism-fixes.patch
index 5b24c18916..0d7974fcdc 100644
--- a/meta/recipes-devtools/qemu/qemu/0006-qemu-Determinism-fixes.patch
+++ b/meta/recipes-devtools/qemu/qemu/0006-qemu-Determinism-fixes.patch
@@ -1,4 +1,4 @@
-From 8b28a9376074067bc2d84d4f77d5c7a42433b31b Mon Sep 17 00:00:00 2001
+From e891928d2248e186c65979cf5a2ba0cff9d00824 Mon Sep 17 00:00:00 2001
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Mon, 1 Mar 2021 13:00:47 +0000
Subject: [PATCH] qemu: Determinism fixes
@@ -11,6 +11,8 @@ meson to pass relative paths but we can fix that in the script.
Upstream-Status: Pending [some version of all/part of this may be accepted]
RP 2021/3/1
+
+Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
scripts/decodetree.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/qemu/qemu/0007-tests-meson.build-use-relative-path-to-refer-to-file.patch b/meta/recipes-devtools/qemu/qemu/0007-tests-meson.build-use-relative-path-to-refer-to-file.patch
index a58c936d06..275c500894 100644
--- a/meta/recipes-devtools/qemu/qemu/0007-tests-meson.build-use-relative-path-to-refer-to-file.patch
+++ b/meta/recipes-devtools/qemu/qemu/0007-tests-meson.build-use-relative-path-to-refer-to-file.patch
@@ -1,4 +1,4 @@
-From 097b75ad8310143decab92f6d1744144e7a4809f Mon Sep 17 00:00:00 2001
+From ac9a866ac807cb1542f26df07b4aad3a06342a99 Mon Sep 17 00:00:00 2001
From: Changqing Li <changqing.li@windriver.com>
Date: Thu, 14 Jan 2021 06:33:04 +0000
Subject: [PATCH] tests/meson.build: use relative path to refer to files
@@ -17,10 +17,10 @@ Signed-off-by: Changqing Li <changqing.li@windriver.com>
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/unit/meson.build b/tests/unit/meson.build
-index d5248ae51..2c581f055 100644
+index 41e8b06c3..ce5df4957 100644
--- a/tests/unit/meson.build
+++ b/tests/unit/meson.build
-@@ -127,17 +127,17 @@ endif
+@@ -124,17 +124,17 @@ endif
if have_system
tests += {
diff --git a/meta/recipes-devtools/qemu/qemu/0008-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch b/meta/recipes-devtools/qemu/qemu/0008-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch
index af0eafb65f..f6e563ad80 100644
--- a/meta/recipes-devtools/qemu/qemu/0008-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch
+++ b/meta/recipes-devtools/qemu/qemu/0008-Define-MAP_SYNC-and-MAP_SHARED_VALIDATE-on-needed-li.patch
@@ -1,4 +1,4 @@
-From 9d5deb767523ea0d1aeecb9960244c702530acad Mon Sep 17 00:00:00 2001
+From c0bfd2c5556afcf4413c81b3fda54a62f2bdd8c8 Mon Sep 17 00:00:00 2001
From: Khem Raj <raj.khem@gmail.com>
Date: Mon, 21 Mar 2022 10:09:38 -0700
Subject: [PATCH] Define MAP_SYNC and MAP_SHARED_VALIDATE on needed linux
diff --git a/meta/recipes-devtools/qemu/qemu/0010-configure-lookup-meson-exutable-from-PATH.patch b/meta/recipes-devtools/qemu/qemu/0010-configure-lookup-meson-exutable-from-PATH.patch
index db88766cf6..430b1aa509 100644
--- a/meta/recipes-devtools/qemu/qemu/0010-configure-lookup-meson-exutable-from-PATH.patch
+++ b/meta/recipes-devtools/qemu/qemu/0010-configure-lookup-meson-exutable-from-PATH.patch
@@ -1,4 +1,4 @@
-From aaec67c133dddda7204d23964732b4b788cbc9ce Mon Sep 17 00:00:00 2001
+From e357ac91b04f733148defe8c133ae8b2085a9a23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Hundeb=C3=B8ll?= <martin@geanix.com>
Date: Wed, 22 May 2024 14:02:55 +0200
Subject: [PATCH] configure: lookup meson exutable from PATH
@@ -13,10 +13,10 @@ Signed-off-by: Kai Kang <kai.kang@windriver.com>
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/configure b/configure
-index 82cace1..83bbda9 100755
+index eea903067..217af781f 100755
--- a/configure
+++ b/configure
-@@ -993,10 +993,7 @@ get_pwd() {
+@@ -981,10 +981,7 @@ get_pwd() {
fi
}
@@ -26,5 +26,5 @@ index 82cace1..83bbda9 100755
-fi
+meson=`which meson`
- # Conditionally ensure Sphinx is installed.
-
+ # On Haiku, meson might show up in a "non-packaged" subfolder instead, see
+ # https://github.com/haiku/haiku/blob/r1beta5/docs/user/storage/storageintro.dox
diff --git a/meta/recipes-devtools/qemu/qemu/0011-qemu-Ensure-pip-and-the-python-venv-aren-t-used-for-.patch b/meta/recipes-devtools/qemu/qemu/0011-qemu-Ensure-pip-and-the-python-venv-aren-t-used-for-.patch
index d04596d313..040931a941 100644
--- a/meta/recipes-devtools/qemu/qemu/0011-qemu-Ensure-pip-and-the-python-venv-aren-t-used-for-.patch
+++ b/meta/recipes-devtools/qemu/qemu/0011-qemu-Ensure-pip-and-the-python-venv-aren-t-used-for-.patch
@@ -1,4 +1,4 @@
-From c9f174b2f7b43e59e91f88c75c8b3e2ee30bfcdd Mon Sep 17 00:00:00 2001
+From 70fa360e5bf72b28960747da47d9b85e650ad312 Mon Sep 17 00:00:00 2001
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Wed, 22 May 2024 13:58:23 +0200
Subject: [PATCH] qemu: Ensure pip and the python venv aren't used for meson
@@ -29,10 +29,10 @@ Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
-index 84e429409..1a9585e8e 100755
+index 217af781f..cf8666337 100755
--- a/configure
+++ b/configure
-@@ -981,14 +981,14 @@ python="$(command -v "$python")"
+@@ -951,14 +951,14 @@ python="$(command -v "$python")"
echo "python determined to be '$python'"
echo "python version: $($python --version)"
@@ -47,5 +47,5 @@ index 84e429409..1a9585e8e 100755
-mkvenv="$python ${source_path}/python/scripts/mkvenv.py"
+mkvenv=true
- # Finish preparing the virtual environment using vendored .whl files
-
+ # Finish preparing the virtual environment using vendored .whl files.
+ # Even if PyPI is allowed, we disallow it here to force installation
diff --git a/meta/recipes-devtools/qemu/qemu/0012-meson-fix-close_range-detection-on-older-glibc.patch b/meta/recipes-devtools/qemu/qemu/0012-meson-fix-close_range-detection-on-older-glibc.patch
new file mode 100644
index 0000000000..3dfc70dad6
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/0012-meson-fix-close_range-detection-on-older-glibc.patch
@@ -0,0 +1,36 @@
+From: Quan Sun <Quan.Sun@windriver.com>
+Subject: [PATCH] meson: fix close_range detection on older glibc
+
+The has_function('close_range') check succeeds at link time on hosts
+with kernel >= 5.9 even when glibc does not declare the function
+(glibc < 2.34, e.g. AlmaLinux 8 / CentOS 8 with glibc 2.28). This
+causes CONFIG_CLOSE_RANGE to be set, but compilation then fails with:
+
+ error: implicit declaration of function 'close_range' [-Wimplicit-function-declaration]
+
+Fix by adding a prefix that includes <unistd.h>, so the meson check
+only succeeds when the C library actually declares close_range() in
+its headers. When the check fails, the existing fallback path in
+oslib-posix.c (which returns false and falls through to the /proc
+based fd closing) is used instead.
+
+Upstream-Status: Submitted [https://lore.kernel.org/qemu-devel/20260522201850.1342167-1-Quan.Sun@windriver.com/]
+
+Signed-off-by: Quan Sun <Quan.Sun@windriver.com>
+---
+ meson.build | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index cf634dfcd8..a1b2c3d4e5 100644
+--- a/meson.build
++++ b/meson.build
+@@ -2632,6 +2632,7 @@ endif
+
+ # has_function
+-config_host_data.set('CONFIG_CLOSE_RANGE', cc.has_function('close_range'))
++config_host_data.set('CONFIG_CLOSE_RANGE',
++ cc.has_function('close_range', prefix: '#include <unistd.h>'))
+ config_host_data.set('CONFIG_ACCEPT4', cc.has_function('accept4'))
+ config_host_data.set('CONFIG_CLOCK_ADJTIME', cc.has_function('clock_adjtime'))
+ config_host_data.set('CONFIG_DUP3', cc.has_function('dup3'))
diff --git a/meta/recipes-devtools/qemu/qemu/0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch b/meta/recipes-devtools/qemu/qemu/0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch
new file mode 100644
index 0000000000..ea37d20d87
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/0013-hw-scsi-vhost-scsi-include-standard-headers-for-vhost-worker-structs.patch
@@ -0,0 +1,35 @@
+From: Quan Sun <Quan.Sun@windriver.com>
+Subject: [PATCH] hw/scsi/vhost-scsi: fix build with older kernel headers
+
+On build hosts with kernel headers older than 6.0, the system's
+<linux/vhost_types.h> does not define struct vhost_vring_worker or
+struct vhost_worker_state, causing compilation of vhost-scsi.c to
+fail:
+
+ error: storage size of 'vq_worker' isn't known
+
+Fix by including standard-headers/linux/vhost_types.h before the
+system's <linux/vhost.h>, matching the existing pattern used in
+hw/virtio/vhost-backend.c. QEMU's bundled header provides the
+struct definitions, and its include guard prevents redefinition
+when the system header pulls in its own vhost_types.h.
+
+Upstream-Status: Submitted [https://lore.kernel.org/qemu-devel/20260525182730.4098543-1-Quan.Sun@windriver.com/]
+
+Signed-off-by: Quan Sun <Quan.Sun@windriver.com>
+---
+ hw/scsi/vhost-scsi.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
+index 699863cc10..10e8fbe503 100644
+--- a/hw/scsi/vhost-scsi.c
++++ b/hw/scsi/vhost-scsi.c
+@@ -15,6 +15,7 @@
+ */
+
+ #include "qemu/osdep.h"
++#include "standard-headers/linux/vhost_types.h"
+ #include <linux/vhost.h>
+ #include <sys/ioctl.h>
+ #include "qapi/error.h"
diff --git a/meta/recipes-devtools/qemu/qemu/fix-strerrorname_np.patch b/meta/recipes-devtools/qemu/qemu/fix-strerrorname_np.patch
deleted file mode 100644
index 524e20a3dd..0000000000
--- a/meta/recipes-devtools/qemu/qemu/fix-strerrorname_np.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From 475dbdbee7ff878d113f45a1a623e9abbf0e55f3 Mon Sep 17 00:00:00 2001
-From: Natanael Copa <ncopa@alpinelinux.org>
-Date: Wed, 18 Sep 2024 16:19:37 -0700
-Subject: [PATCH] target/riscv/kvm: do not use non-portable strerrorname_np()
-
-strerrorname_np is non-portable and breaks building with musl libc.
-
-Use strerror(errno) instead, like we do other places.
-
-Upstream-Status: Submitted [https://mail.gnu.org/archive/html/qemu-stable/2023-12/msg00069.html]
-
-Cc: qemu-stable@nongnu.org
-Fixes: commit 082e9e4a58ba (target/riscv/kvm: improve 'init_multiext_cfg' error
-msg)
-Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2041
-Buglink: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15541
-Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
----
- target/riscv/kvm/kvm-cpu.c | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
-index e06d2126b..e1cc02fba 100644
---- a/target/riscv/kvm/kvm-cpu.c
-+++ b/target/riscv/kvm/kvm-cpu.c
-@@ -1994,8 +1994,7 @@ static bool kvm_cpu_realize(CPUState *cs, Error **errp)
- if (riscv_has_ext(&cpu->env, RVV)) {
- ret = prctl(PR_RISCV_V_SET_CONTROL, PR_RISCV_V_VSTATE_CTRL_ON);
- if (ret) {
-- error_setg(errp, "Error in prctl PR_RISCV_V_SET_CONTROL, code: %s",
-- strerrorname_np(errno));
-+ error_setg(errp, "Error in prctl PR_RISCV_V_SET_CONTROL, error %d", errno);
- return false;
- }
- }
diff --git a/meta/recipes-devtools/qemu/qemu_10.2.0.bb b/meta/recipes-devtools/qemu/qemu_11.0.0.bb
similarity index 100%
rename from meta/recipes-devtools/qemu/qemu_10.2.0.bb
rename to meta/recipes-devtools/qemu/qemu_11.0.0.bb
--
2.49.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-28 20:26 [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan.Sun
@ 2026-05-29 12:42 ` Mathieu Dubois-Briand
2026-05-29 14:44 ` Quan Sun
2026-06-02 16:57 ` Ross Burton
1 sibling, 1 reply; 28+ messages in thread
From: Mathieu Dubois-Briand @ 2026-05-29 12:42 UTC (permalink / raw)
To: Quan.Sun, openembedded-core
On Thu May 28, 2026 at 10:26 PM CEST, Quan Sun via lists.openembedded.org wrote:
> From: Quan Sun <Quan.Sun@windriver.com>
>
> Upgrade QEMU to version 11.0.0.
>
Hi,
Thanks for the new version.
It looks like we are almost there, I now have just one selftest failing:
2026-05-29 08:23:23,583 - oe-selftest - INFO - runtime_test.TestImage.test_testimage_virgl_gtk_sdl (subunit.RemotedTestCase)
2026-05-29 08:23:23,584 - oe-selftest - INFO - ... FAIL
...
runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: -qmp unix:./.i1y4asol,server,wait: info: QEMU waiting for connection on: disconnected:unix:./.i1y4asol,server=on
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
glx: failed to create dri3 screen
failed to load driver: vgem
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
Can you have a look at the issue?
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 12:42 ` Mathieu Dubois-Briand
@ 2026-05-29 14:44 ` Quan Sun
2026-05-29 15:23 ` Alexander Kanavin
0 siblings, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-05-29 14:44 UTC (permalink / raw)
To: Mathieu Dubois-Briand, openembedded-core
On 5/29/26 8:42 AM, Mathieu Dubois-Briand wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Thu May 28, 2026 at 10:26 PM CEST, Quan Sun via lists.openembedded.org wrote:
>> From: Quan Sun <Quan.Sun@windriver.com>
>>
>> Upgrade QEMU to version 11.0.0.
>>
> Hi,
>
> Thanks for the new version.
>
> It looks like we are almost there, I now have just one selftest failing:
> 2026-05-29 08:23:23,583 - oe-selftest - INFO - runtime_test.TestImage.test_testimage_virgl_gtk_sdl (subunit.RemotedTestCase)
> 2026-05-29 08:23:23,584 - oe-selftest - INFO - ... FAIL
> ...
> runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: -qmp unix:./.i1y4asol,server,wait: info: QEMU waiting for connection on: disconnected:unix:./.i1y4asol,server=on
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.hle [bit 4]
> qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.rtm [bit 11]
> glx: failed to create dri3 screen
> failed to load driver: vgem
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
>
> Can you have a look at the issue?
>
> Thanks,
> Mathieu
Hi Mathieu,
It seems this issue is not caused by the qemu upgrade. I also asked an
AI agent to carefully examine the build/test logs, and the following is
what it says:
--- Root Cause ---
The only failing test is
runtime_test.TestImage.test_testimage_virgl_gtk_sdl — and it
is NOT caused by the QEMU 10.2→11.0 upgrade. It's a GPU/graphics driver
issue on the
autobuilder worker host.
The key error messages are:
glx: failed to create dri3 screen
failed to load driver: vgem
This means QEMU 11.0's virgl (GPU virtualization) display backend
(-display gtk,gl=on)
failed because the autobuilder host (ubuntu2510-vk-1) doesn't have a
working DRI3/GPU
driver setup. The vgem (Virtual GEM) driver failed to load, which
prevents virgl from
initializing OpenGL, which causes QEMU to exit immediately before the
QMP monitor
connection can be established.
--- Why this is NOT a QEMU upgrade regression ---
1. 685 out of 686 tests passed — including many other QEMU-based tests
(runqemu boot
tests, testimage_dnf, testimage_install, testimage_slirp,
testimage_virgl_headless,
etc.)
2. The test_testimage_virgl_headless test (virgl without GTK/SDL
display) passed fine —
confirming QEMU itself works.
3. The failure is specifically in the GTK+SDL+GL display path, which
requires a
functional GPU/DRI3 stack on the host.
4. This is a known class of intermittent/environment-dependent failure
on CI workers
that lack proper GPU passthrough.
Please check if it's a pre-existing autobuilder infrastructure issue —
the worker ubuntu2510-vk-1 doesn
't have a working DRI3 GPU driver for virgl's GTK/SDL/GL display mode.
This test
may likely also fail (or maybe flaky) with QEMU 10.2 on that same worker.
Thanks,
Quan
>
> --
> Mathieu Dubois-Briand, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 14:44 ` Quan Sun
@ 2026-05-29 15:23 ` Alexander Kanavin
2026-05-29 15:49 ` Richard Purdie
2026-05-29 15:52 ` [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan Sun
0 siblings, 2 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-05-29 15:23 UTC (permalink / raw)
To: Quan.Sun; +Cc: Mathieu Dubois-Briand, openembedded-core
On Fri, 29 May 2026 at 16:45, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> > glx: failed to create dri3 screen
> > failed to load driver: vgem
> >
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
> > https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
> >
> > Can you have a look at the issue?
> It seems this issue is not caused by the qemu upgrade. I also asked an
> AI agent to carefully examine the build/test logs, and the following is
> what it says:
Unfortunately AI has produced a total hallucination in its analysis,
because it looks only at the build log given to it, not at the actual
change that is being tested (e.g. it wouldn't see in that log that
there is a qemu update, and it wouldn't go and analyse the qemu own
changelog and commit history, and it wouldn't run the same test
against qemu 10.x to narrow it down and so on).
I went and tried this test with qemu 10.x on the same host, and it
passes just fine:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3928
Then I cherry picked the qemu 11.x patch, and the test then fails:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
It's still possible something is misconfigured on the host (it runs
tiger vnc standalone server to allow X clients such as qemu to render
into it), but the issue is clearly triggered by the version upgrade.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 15:23 ` Alexander Kanavin
@ 2026-05-29 15:49 ` Richard Purdie
2026-05-29 16:10 ` Quan Sun
2026-05-29 15:52 ` [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan Sun
1 sibling, 1 reply; 28+ messages in thread
From: Richard Purdie @ 2026-05-29 15:49 UTC (permalink / raw)
To: alex.kanavin, Quan.Sun; +Cc: Mathieu Dubois-Briand, openembedded-core
On Fri, 2026-05-29 at 17:23 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
> On Fri, 29 May 2026 at 16:45, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> > > glx: failed to create dri3 screen
> > > failed to load driver: vgem
> > >
> > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
> > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
> > >
> > > Can you have a look at the issue?
> > It seems this issue is not caused by the qemu upgrade. I also asked
> > an
> > AI agent to carefully examine the build/test logs, and the
> > following is
> > what it says:
>
> Unfortunately AI has produced a total hallucination in its analysis,
> because it looks only at the build log given to it, not at the actual
> change that is being tested (e.g. it wouldn't see in that log that
> there is a qemu update, and it wouldn't go and analyse the qemu own
> changelog and commit history, and it wouldn't run the same test
> against qemu 10.x to narrow it down and so on).
>
> I went and tried this test with qemu 10.x on the same host, and it
> passes just fine:
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3928
>
> Then I cherry picked the qemu 11.x patch, and the test then fails:
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
>
> It's still possible something is misconfigured on the host (it runs
> tiger vnc standalone server to allow X clients such as qemu to render
> into it), but the issue is clearly triggered by the version upgrade.
I should add, I looked into a couple of the failures on the autobuilder
and it appeared qemu is segfaulting after the upgrade. I'm fairly sure
that is related to the upgrade as it doesn't do it before.
Stack trace of thread 2714954:
#0 0x00007fec6367b4f4 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0x924f4)
#1 0x00007fec603c0f40 wl_proxy_create_wrapper (libwayland-client.so.0 + 0x8f40)
#2 0x00007fec60182bc0 n/a (libEGL.so.1 + 0x2bbc0)
#3 0x00007fec6017a4e0 n/a (libEGL.so.1 + 0x234e0)
#4 0x00007fec6016aa9c eglInitialize (libEGL.so.1 + 0x13a9c)
#5 0x00007fec64a89a8c n/a (libSDL2-2.0.so.0 + 0xbaa8c)
#6 0x00007fec64a98226 n/a (libSDL2-2.0.so.0 + 0xc9226)
#7 0x00007fec64a9ab19 n/a (libSDL2-2.0.so.0 + 0xcbb19)
#8 0x0000558d31710aa4 n/a (qemu-system-x86_64 + 0x6acaa4)
#9 0x0000558d3171224e n/a (qemu-system-x86_64 + 0x6ae24e)
#10 0x0000558d31710732 n/a (qemu-system-x86_64 + 0x6ac732)
#11 0x0000558d3164b554 n/a (qemu-system-x86_64 + 0x5e7554)
#12 0x0000558d313a8e59 n/a (qemu-system-x86_64 + 0x344e59)
#13 0x00007fec6360efab __libc_start_call_main (libc.so.6 + 0x25fab)
#14 0x00007fec6360f0cb __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x260cb)
#15 0x0000558d313aa015 n/a (qemu-system-x86_64 + 0x346015)
Stack trace of thread 2714967:
#0 0x00007fec63680102 __syscall_cancel_arch (libc.so.6 + 0x97102)
#1 0x00007fec63674fb8 __internal_syscall_cancel (libc.so.6 + 0x8bfb8)
#2 0x00007fec6367529c __futex_abstimed_wait_common (libc.so.6 + 0x8c29c)
#3 0x00007fec636779a8 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x8e9a8)
#4 0x00007fec41996ff9 n/a (libgallium-26.0.6.so + 0x596ff9)
#5 0x00007fec41c64ee3 n/a (libgallium-26.0.6.so + 0x864ee3)
#6 0x00007fec41996f37 n/a (libgallium-26.0.6.so + 0x596f37)
#7 0x00007fec6367832c start_thread (libc.so.6 + 0x8f32c)
#8 0x00007fec636f3b2c __clone3 (libc.so.6 + 0x10ab2c)
[and more but probably not so interesting]
so it is failing in eglInitialize().
Cheers,
Richard
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 15:23 ` Alexander Kanavin
2026-05-29 15:49 ` Richard Purdie
@ 2026-05-29 15:52 ` Quan Sun
2026-05-29 16:17 ` Alexander Kanavin
1 sibling, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-05-29 15:52 UTC (permalink / raw)
To: Alexander Kanavin; +Cc: Mathieu Dubois-Briand, openembedded-core
On 5/29/26 11:23 AM, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 29 May 2026 at 16:45, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>>> glx: failed to create dri3 screen
>>> failed to load driver: vgem
>>>
>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
>>>
>>> Can you have a look at the issue?
>> It seems this issue is not caused by the qemu upgrade. I also asked an
>> AI agent to carefully examine the build/test logs, and the following is
>> what it says:
> Unfortunately AI has produced a total hallucination in its analysis,
> because it looks only at the build log given to it, not at the actual
> change that is being tested (e.g. it wouldn't see in that log that
> there is a qemu update, and it wouldn't go and analyse the qemu own
> changelog and commit history, and it wouldn't run the same test
> against qemu 10.x to narrow it down and so on).
>
> I went and tried this test with qemu 10.x on the same host, and it
> passes just fine:
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3928
>
> Then I cherry picked the qemu 11.x patch, and the test then fails:
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
>
> It's still possible something is misconfigured on the host (it runs
> tiger vnc standalone server to allow X clients such as qemu to render
> into it), but the issue is clearly triggered by the version upgrade.
>
> Alex
Hi Alex,
I looked at your test logs and not sure if you performed the test by
really using the qemu 11.0.0. (Note the QEMU binary used in the test was
built from sstate cache (1851 of
1852 tasks were cached —
Sstate summary: Wanted 187 Local 187 ... 100% match, 100% complete),
meaning it may have used
whatever QEMU version is already in master's sstate, not a freshly-built
QEMU 11.0 ?)
Regardless of the AI agent, but the earlier test really failed on the
worker ubuntu2510-vk-1 because that host lacks GPU/DRI3 drivers. Have
you performed your test on this worker ubuntu2510-vk-1 ?
Thanks,
Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 15:49 ` Richard Purdie
@ 2026-05-29 16:10 ` Quan Sun
2026-05-29 16:29 ` Alexander Kanavin
0 siblings, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-05-29 16:10 UTC (permalink / raw)
To: Richard Purdie, alex.kanavin; +Cc: Mathieu Dubois-Briand, openembedded-core
On 5/29/26 11:49 AM, Richard Purdie wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 2026-05-29 at 17:23 +0200, Alexander Kanavin via
> lists.openembedded.org wrote:
>> On Fri, 29 May 2026 at 16:45, Quan Sun via lists.openembedded.org
>> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>>>> glx: failed to create dri3 screen
>>>> failed to load driver: vgem
>>>>
>>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3924
>>>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3786
>>>>
>>>> Can you have a look at the issue?
>>> It seems this issue is not caused by the qemu upgrade. I also asked
>>> an
>>> AI agent to carefully examine the build/test logs, and the
>>> following is
>>> what it says:
>> Unfortunately AI has produced a total hallucination in its analysis,
>> because it looks only at the build log given to it, not at the actual
>> change that is being tested (e.g. it wouldn't see in that log that
>> there is a qemu update, and it wouldn't go and analyse the qemu own
>> changelog and commit history, and it wouldn't run the same test
>> against qemu 10.x to narrow it down and so on).
>>
>> I went and tried this test with qemu 10.x on the same host, and it
>> passes just fine:
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3928
>>
>> Then I cherry picked the qemu 11.x patch, and the test then fails:
>>
>> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
>>
>> It's still possible something is misconfigured on the host (it runs
>> tiger vnc standalone server to allow X clients such as qemu to render
>> into it), but the issue is clearly triggered by the version upgrade.
>
> I should add, I looked into a couple of the failures on the autobuilder
> and it appeared qemu is segfaulting after the upgrade. I'm fairly sure
> that is related to the upgrade as it doesn't do it before.
>
> Stack trace of thread 2714954:
> #0 0x00007fec6367b4f4 __pthread_mutex_lock@GLIBC_2.2.5 (libc.so.6 + 0x924f4)
> #1 0x00007fec603c0f40 wl_proxy_create_wrapper (libwayland-client.so.0 + 0x8f40)
> #2 0x00007fec60182bc0 n/a (libEGL.so.1 + 0x2bbc0)
> #3 0x00007fec6017a4e0 n/a (libEGL.so.1 + 0x234e0)
> #4 0x00007fec6016aa9c eglInitialize (libEGL.so.1 + 0x13a9c)
> #5 0x00007fec64a89a8c n/a (libSDL2-2.0.so.0 + 0xbaa8c)
> #6 0x00007fec64a98226 n/a (libSDL2-2.0.so.0 + 0xc9226)
> #7 0x00007fec64a9ab19 n/a (libSDL2-2.0.so.0 + 0xcbb19)
> #8 0x0000558d31710aa4 n/a (qemu-system-x86_64 + 0x6acaa4)
> #9 0x0000558d3171224e n/a (qemu-system-x86_64 + 0x6ae24e)
> #10 0x0000558d31710732 n/a (qemu-system-x86_64 + 0x6ac732)
> #11 0x0000558d3164b554 n/a (qemu-system-x86_64 + 0x5e7554)
> #12 0x0000558d313a8e59 n/a (qemu-system-x86_64 + 0x344e59)
> #13 0x00007fec6360efab __libc_start_call_main (libc.so.6 + 0x25fab)
> #14 0x00007fec6360f0cb __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x260cb)
> #15 0x0000558d313aa015 n/a (qemu-system-x86_64 + 0x346015)
>
>
> Stack trace of thread 2714967:
> #0 0x00007fec63680102 __syscall_cancel_arch (libc.so.6 + 0x97102)
> #1 0x00007fec63674fb8 __internal_syscall_cancel (libc.so.6 + 0x8bfb8)
> #2 0x00007fec6367529c __futex_abstimed_wait_common (libc.so.6 + 0x8c29c)
> #3 0x00007fec636779a8 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x8e9a8)
> #4 0x00007fec41996ff9 n/a (libgallium-26.0.6.so + 0x596ff9)
> #5 0x00007fec41c64ee3 n/a (libgallium-26.0.6.so + 0x864ee3)
> #6 0x00007fec41996f37 n/a (libgallium-26.0.6.so + 0x596f37)
> #7 0x00007fec6367832c start_thread (libc.so.6 + 0x8f32c)
> #8 0x00007fec636f3b2c __clone3 (libc.so.6 + 0x10ab2c)
>
> [and more but probably not so interesting]
>
> so it is failing in eglInitialize().
>
> Cheers,
>
> Richard
Hi Richard,
This is likely a real QEMU 11.0 regression, but may not be in QEMU's
code itself. The QEMU 11.0 likely changed its display initialization to
be multi-threaded or reordered it, triggering a race condition in the
host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
solve the issue.
This issue is different from the "glx: failed to create dri3 screen /
failed to load driver: vgem error" seen earlier, which was a missing GPU
driver issue on the host.
If you have any detailed logs, please share with me and so I have more
contexts.
Thanks,
Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 15:52 ` [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan Sun
@ 2026-05-29 16:17 ` Alexander Kanavin
0 siblings, 0 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-05-29 16:17 UTC (permalink / raw)
To: Quan.Sun; +Cc: Mathieu Dubois-Briand, openembedded-core
On Fri, 29 May 2026 at 17:52, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> I looked at your test logs and not sure if you performed the test by
> really using the qemu 11.0.0. (Note the QEMU binary used in the test was
> built from sstate cache (1851 of
> 1852 tasks were cached —
> Sstate summary: Wanted 187 Local 187 ... 100% match, 100% complete),
> meaning it may have used
> whatever QEMU version is already in master's sstate, not a freshly-built
> QEMU 11.0 ?)
This is the second execution of bitbake after everything is already
built in the first execution, and bitbake only needs to run the
testimage task for core-image-minimal. The actual build of the image
and qemu is not in the logs, but I assure you, it's building and using
11.0. You can also see that it's using my
akanavin/package-version-updates branch, not master:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930/steps/9/logs/property_changes
https://git.openembedded.org/openembedded-core-contrib/log/?h=akanavin/package-version-updates
> Regardless of the AI agent, but the earlier test really failed on the
> worker ubuntu2510-vk-1 because that host lacks GPU/DRI3 drivers. Have
> you performed your test on this worker ubuntu2510-vk-1 ?
Yes. You can see at the top of the page that both tests used this worker, e.g.:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3930
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 16:10 ` Quan Sun
@ 2026-05-29 16:29 ` Alexander Kanavin
2026-05-29 16:47 ` Quan Sun
2026-06-05 6:35 ` ui: Regression calling eglInitialize() since v11.0.0 Philippe Mathieu-Daudé
0 siblings, 2 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-05-29 16:29 UTC (permalink / raw)
To: Quan.Sun; +Cc: Richard Purdie, Mathieu Dubois-Briand, openembedded-core
On Fri, 29 May 2026 at 18:10, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> This is likely a real QEMU 11.0 regression, but may not be in QEMU's
> code itself. The QEMU 11.0 likely changed its display initialization to
> be multi-threaded or reordered it, triggering a race condition in the
> host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
> solve the issue.
>
> This issue is different from the "glx: failed to create dri3 screen /
> failed to load driver: vgem error" seen earlier, which was a missing GPU
> driver issue on the host.
>
> If you have any detailed logs, please share with me and so I have more
> contexts.
It's the same issue, I assure you. Qemu 10.x prints nothing and simply
starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
(even though there's no wayland running on the build hosts), and then
finally crashes, with the traceback that RP provided.
I don't think it's a race condition, as the failure is deterministic,
but I agree that something has changed in qemu's GL initialization
sequence.
Unfortunately there are no more detailed logs than this. We've
considered disabling this test, as accelerated rendering directly into
gtk/sdl windows is tricky to support, complicated to reproduce (with
regressions like this), and has limited use. I've promised RP to write
up a proposal to oe-architecture, and I'll get to it :)
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 16:29 ` Alexander Kanavin
@ 2026-05-29 16:47 ` Quan Sun
2026-05-29 17:18 ` Alexander Kanavin
2026-06-05 6:35 ` ui: Regression calling eglInitialize() since v11.0.0 Philippe Mathieu-Daudé
1 sibling, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-05-29 16:47 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Richard Purdie, Mathieu Dubois-Briand, openembedded-core
On 5/29/26 12:29 PM, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 29 May 2026 at 18:10, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>> This is likely a real QEMU 11.0 regression, but may not be in QEMU's
>> code itself. The QEMU 11.0 likely changed its display initialization to
>> be multi-threaded or reordered it, triggering a race condition in the
>> host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
>> solve the issue.
>>
>> This issue is different from the "glx: failed to create dri3 screen /
>> failed to load driver: vgem error" seen earlier, which was a missing GPU
>> driver issue on the host.
>>
>> If you have any detailed logs, please share with me and so I have more
>> contexts.
> It's the same issue, I assure you. Qemu 10.x prints nothing and simply
> starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
> (even though there's no wayland running on the build hosts), and then
> finally crashes, with the traceback that RP provided.
>
> I don't think it's a race condition, as the failure is deterministic,
> but I agree that something has changed in qemu's GL initialization
> sequence.
>
> Unfortunately there are no more detailed logs than this. We've
> considered disabling this test, as accelerated rendering directly into
> gtk/sdl windows is tricky to support, complicated to reproduce (with
> regressions like this), and has limited use. I've promised RP to write
> up a proposal to oe-architecture, and I'll get to it :)
>
> Alex
Then it could be this:
The QEMU 11.0 changed its GL display initialization sequence. On
headless build hosts (no Wayland, no proper GPU), QEMU 10.x would
silently fall through and start, while QEMU 11.0 now probes more
aggressively:
1. Tries GLX/DRI3 → fails (glx: failed to create dri3 screen, failed to
load driver: vgem)
2. Tries Wayland/EGL → crashes (the segfault in eglInitialize →
wl_proxy_create_wrapper)
It's not a race — it's a deterministic crash because QEMU 11.0's new
init path tries
to call into Wayland client code on a host where Wayland isn't running,
and that code
path hits a NULL pointer or invalid state in wl_proxy_create_wrapper.
Still, the upgrade itself may be fine — all actual QEMU
functionality works (685/686 tests pass). The single failure is in
test_testimage_virgl_gtk_sdl, which tests hardware-accelerated GL
rendering into a GTK
/SDL window — something that doesn't work on headless CI hosts
regardless, and QEMU
11.0 just crashes harder than 10.x did when it fails. The test itself
may be a candidate
for removal/rework.
-Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 16:47 ` Quan Sun
@ 2026-05-29 17:18 ` Alexander Kanavin
2026-05-29 18:13 ` Quan Sun
0 siblings, 1 reply; 28+ messages in thread
From: Alexander Kanavin @ 2026-05-29 17:18 UTC (permalink / raw)
To: Quan.Sun; +Cc: Richard Purdie, Mathieu Dubois-Briand, openembedded-core
On Fri, 29 May 2026 at 18:47, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> The QEMU 11.0 changed its GL display initialization sequence. On
> headless build hosts (no Wayland, no proper GPU), QEMU 10.x would
> silently fall through and start, while QEMU 11.0 now probes more
> aggressively:
>
> 1. Tries GLX/DRI3 → fails (glx: failed to create dri3 screen, failed to
> load driver: vgem)
> 2. Tries Wayland/EGL → crashes (the segfault in eglInitialize →
> wl_proxy_create_wrapper)
>
> It's not a race — it's a deterministic crash because QEMU 11.0's new
> init path tries
> to call into Wayland client code on a host where Wayland isn't running,
> and that code
> path hits a NULL pointer or invalid state in wl_proxy_create_wrapper.
>
> Still, the upgrade itself may be fine — all actual QEMU
> functionality works (685/686 tests pass). The single failure is in
> test_testimage_virgl_gtk_sdl, which tests hardware-accelerated GL
> rendering into a GTK
> /SDL window — something that doesn't work on headless CI hosts
> regardless, and QEMU
> 11.0 just crashes harder than 10.x did when it fails. The test itself
> may be a candidate
> for removal/rework.
qemu 10.x does not crash, or silently fail, and it is able to open sdl
and gtk windows even on headless hosts without GPU. Yocto CI is
specifically set up to support it: it's runing Tiger VNC server that X
clients (such as qemu) can connect to, and qemu is using mesa's
llvmpipe renderer which does not require a physical GPU.
Are you using AI to write out argumentation here as well, or are these
your own thoughts? Please be clear about this. I'd be happy to correct
you, but I would not want to spend too much time time correcting AI,
because I don't think it is going to provide sudden helpful insights.
To get to the bottom of it, someone needs to set up a gdb session and
step through the code of 11.x and 10.x initializations, finding out
why one falls through to the crashing wayland step, and the other does
not. AI is not capable of doing that kind of reproducing the issue,
and then debugging it, not yet at least.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 17:18 ` Alexander Kanavin
@ 2026-05-29 18:13 ` Quan Sun
2026-05-29 18:43 ` Alexander Kanavin
0 siblings, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-05-29 18:13 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Richard Purdie, Mathieu Dubois-Briand, openembedded-core
On 5/29/26 1:18 PM, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 29 May 2026 at 18:47, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>> The QEMU 11.0 changed its GL display initialization sequence. On
>> headless build hosts (no Wayland, no proper GPU), QEMU 10.x would
>> silently fall through and start, while QEMU 11.0 now probes more
>> aggressively:
>>
>> 1. Tries GLX/DRI3 → fails (glx: failed to create dri3 screen, failed to
>> load driver: vgem)
>> 2. Tries Wayland/EGL → crashes (the segfault in eglInitialize →
>> wl_proxy_create_wrapper)
>>
>> It's not a race — it's a deterministic crash because QEMU 11.0's new
>> init path tries
>> to call into Wayland client code on a host where Wayland isn't running,
>> and that code
>> path hits a NULL pointer or invalid state in wl_proxy_create_wrapper.
>>
>> Still, the upgrade itself may be fine — all actual QEMU
>> functionality works (685/686 tests pass). The single failure is in
>> test_testimage_virgl_gtk_sdl, which tests hardware-accelerated GL
>> rendering into a GTK
>> /SDL window — something that doesn't work on headless CI hosts
>> regardless, and QEMU
>> 11.0 just crashes harder than 10.x did when it fails. The test itself
>> may be a candidate
>> for removal/rework.
> qemu 10.x does not crash, or silently fail, and it is able to open sdl
> and gtk windows even on headless hosts without GPU. Yocto CI is
> specifically set up to support it: it's runing Tiger VNC server that X
> clients (such as qemu) can connect to, and qemu is using mesa's
> llvmpipe renderer which does not require a physical GPU.
>
> Are you using AI to write out argumentation here as well, or are these
> your own thoughts? Please be clear about this. I'd be happy to correct
> you, but I would not want to spend too much time time correcting AI,
> because I don't think it is going to provide sudden helpful insights.
> To get to the bottom of it, someone needs to set up a gdb session and
> step through the code of 11.x and 10.x initializations, finding out
> why one falls through to the crashing wayland step, and the other does
> not. AI is not capable of doing that kind of reproducing the issue,
> and then debugging it, not yet at least.
>
> Alex
Hi Alex,
Because I haven't got much info when it failed, and through these email
exchanges I know more and more about what's happening - you guys know
more, although AI was used in analyzing some of the behaviors, I'm not
blind to trust it - sorry that it bothered you. But apparently QEMU 11.0
changed its GL initialization and now tries Wayland/EGL paths before (or
instead of) the GLX/X11 path that worked with 10.x. On these CI hosts
there's no Wayland, so it crashes when it shouldn't be probing Wayland
at all. We'll investigate why this is the case.
Thanks,
Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-29 18:13 ` Quan Sun
@ 2026-05-29 18:43 ` Alexander Kanavin
0 siblings, 0 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-05-29 18:43 UTC (permalink / raw)
To: Quan Sun; +Cc: Richard Purdie, Mathieu Dubois-Briand, openembedded-core
On Fri, 29 May 2026 at 20:14, Quan Sun <Quan.Sun@windriver.com> wrote:
> Because I haven't got much info when it failed, and through these email
> exchanges I know more and more about what's happening - you guys know
> more, although AI was used in analyzing some of the behaviors, I'm not
> blind to trust it - sorry that it bothered you. But apparently QEMU 11.0
> changed its GL initialization and now tries Wayland/EGL paths before (or
> instead of) the GLX/X11 path that worked with 10.x. On these CI hosts
> there's no Wayland, so it crashes when it shouldn't be probing Wayland
> at all. We'll investigate why this is the case.
Thanks, this sounds about right.
The option of disabling the failing test (and possibly disabling
qemu's sdl UI frontend by default, in favour of its own built-in vnc
server) is on the table too, I just need to write up the rationale.
It's now Friday evening here, so I'll get to it later :)
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-05-28 20:26 [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan.Sun
2026-05-29 12:42 ` Mathieu Dubois-Briand
@ 2026-06-02 16:57 ` Ross Burton
2026-06-02 19:25 ` Quan Sun
1 sibling, 1 reply; 28+ messages in thread
From: Ross Burton @ 2026-06-02 16:57 UTC (permalink / raw)
To: Quan.Sun@windriver.com; +Cc: openembedded-core@lists.openembedded.org
On 28 May 2026, at 21:26, Quan Sun via lists.openembedded.org <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> - Add python3-qemu-qmp recipe (0.0.6) as a separate package. The QMP
> Python library was removed from the QEMU source tree in 11.0.0 and
> split into its own upstream project. This is needed by
> qemu-system-native for testimage integration.
> Add an entry for this recipe in maintainers.inc.
Can you split this piece out and send it separately? We can merge this now, whilst the graphic and other issues are fixed and tested.
Thanks,
Ross
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-06-02 16:57 ` Ross Burton
@ 2026-06-02 19:25 ` Quan Sun
2026-06-02 19:44 ` Alexander Kanavin
[not found] ` <18B55B33A6799835.3712505@lists.openembedded.org>
0 siblings, 2 replies; 28+ messages in thread
From: Quan Sun @ 2026-06-02 19:25 UTC (permalink / raw)
To: Ross Burton; +Cc: openembedded-core@lists.openembedded.org
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
On 6/2/26 12:57 PM, Ross Burton wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On 28 May 2026, at 21:26, Quan Sun via lists.openembedded.org<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>> - Add python3-qemu-qmp recipe (0.0.6) as a separate package. The QMP
>> Python library was removed from the QEMU source tree in 11.0.0 and
>> split into its own upstream project. This is needed by
>> qemu-system-native for testimage integration.
>> Add an entry for this recipe in maintainers.inc.
> Can you split this piece out and send it separately? We can merge this now, whilst the graphic and other issues are fixed and tested.
>
> Thanks,
> Ross
Hello Ross,
Do you mean I add the the standalone python3-qemu-qmp package to the
existing qemu 10.2.0 recipe and have qemu-system-native use it instead
of manually installing from the QEMU source, i.e.,
1. Add python3-qemu-qmp_0.0.6.bb to meta/recipes-devtools/qemu/
2. In qemu-system-native_10.2.0.bb: add python3-qemu-qmp-native to
DEPENDS and remove the manual install -D ${S}/python/qemu/qmp/* block
from do_install:append()
Or do you mean something else?
*As Alex just sent out a patch that would unblock the qemu upgrade to
11.0.0, which means I don't need to take any actions here?*
Regarding the graphics issue, I do find something interesting: maybe the
upstream qemu commit 52053b7e0a ("ui/sdl2: Implement dpy dmabuf
functions") which added the sdl2_set_hint_x11_force_egl() function. This
function is supposed to force SDL to use EGL instead of GLX (which would
work with llvmpipe), and most probably something could be wrong there.
Unfortunately, I'm currently busy with other things and not performing
further investigations.
Thanks,
Quan
[-- Attachment #2: Type: text/html, Size: 2679 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-06-02 19:25 ` Quan Sun
@ 2026-06-02 19:44 ` Alexander Kanavin
[not found] ` <18B55B33A6799835.3712505@lists.openembedded.org>
1 sibling, 0 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-02 19:44 UTC (permalink / raw)
To: Quan.Sun; +Cc: Ross Burton, openembedded-core@lists.openembedded.org
On Tue, 2 Jun 2026 at 21:25, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> Can you split this piece out and send it separately? We can merge this now, whilst the graphic and other issues are fixed and tested.
>
> Thanks,
> Ross
>
> Hello Ross,
>
> Do you mean I add the the standalone python3-qemu-qmp package to the existing qemu 10.2.0 recipe and have qemu-system-native use it instead of manually installing from the QEMU source, i.e.,
>
> 1. Add python3-qemu-qmp_0.0.6.bb to meta/recipes-devtools/qemu/
> 2. In qemu-system-native_10.2.0.bb: add python3-qemu-qmp-native to DEPENDS and remove the manual install -D ${S}/python/qemu/qmp/* block from do_install:append()
>
Yes, basically split the introduction of separate qemu-qmp recipe (and
tweaks to existing qemu recipe to use it) into its own commit, and
then do the qemu version update in a second, separate commit on top of
that. That makes the changes easier to review and merge.
> As Alex just sent out a patch that would unblock the qemu upgrade to 11.0.0, which means I don't need to take any actions here?
>
> Regarding the graphics issue, I do find something interesting: maybe the upstream qemu commit 52053b7e0a ("ui/sdl2: Implement dpy dmabuf functions") which added the sdl2_set_hint_x11_force_egl() function. This function is supposed to force SDL to use EGL instead of GLX (which would work with llvmpipe), and most probably something could be wrong there. Unfortunately, I'm currently busy with other things and not performing further investigations.
Thanks, that upstream change indeed does look promising as a possible
investigation lead. For now you don't need to do anything; if my
changes pass CI and review, then it's resolved that way.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
[not found] ` <18B55B33A6799835.3712505@lists.openembedded.org>
@ 2026-06-04 11:09 ` Alexander Kanavin
2026-06-04 15:58 ` Richard Purdie
0 siblings, 1 reply; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-04 11:09 UTC (permalink / raw)
To: alex.kanavin
Cc: Quan.Sun, Ross Burton, openembedded-core@lists.openembedded.org
On Tue, 2 Jun 2026 at 21:45, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
> Yes, basically split the introduction of separate qemu-qmp recipe (and
> tweaks to existing qemu recipe to use it) into its own commit, and
> then do the qemu version update in a second, separate commit on top of
> that. That makes the changes easier to review and merge.
I went ahead and have done the split, and sent the patches.
Unfortunately the commit author has been reset to me, even though
you've done almost all the work, but your signed-off-by is kept.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0
2026-06-04 11:09 ` Alexander Kanavin
@ 2026-06-04 15:58 ` Richard Purdie
0 siblings, 0 replies; 28+ messages in thread
From: Richard Purdie @ 2026-06-04 15:58 UTC (permalink / raw)
To: alex.kanavin
Cc: Quan.Sun, Ross Burton, openembedded-core@lists.openembedded.org
On Thu, 2026-06-04 at 13:09 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
> On Tue, 2 Jun 2026 at 21:45, Alexander Kanavin via
> lists.openembedded.org
> <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> > Yes, basically split the introduction of separate qemu-qmp recipe
> > (and
> > tweaks to existing qemu recipe to use it) into its own commit, and
> > then do the qemu version update in a second, separate commit on top
> > of
> > that. That makes the changes easier to review and merge.
>
> I went ahead and have done the split, and sent the patches.
> Unfortunately the commit author has been reset to me, even though
> you've done almost all the work, but your signed-off-by is kept.
I've added a note to the commit messages saying they were based on a
patch from Quan.
Cheers,
Richard
^ permalink raw reply [flat|nested] 28+ messages in thread
* ui: Regression calling eglInitialize() since v11.0.0
2026-05-29 16:29 ` Alexander Kanavin
2026-05-29 16:47 ` Quan Sun
@ 2026-06-05 6:35 ` Philippe Mathieu-Daudé
2026-06-05 8:10 ` Daniel P. Berrangé
1 sibling, 1 reply; 28+ messages in thread
From: Philippe Mathieu-Daudé @ 2026-06-05 6:35 UTC (permalink / raw)
To: Akihiko Odaki, Marc-André Lureau
Cc: Alexander Kanavin, Richard Purdie, Mathieu Dubois-Briand,
openembedded-core, Quan.Sun, QEMU Developers
On 29/5/26 18:29, Alexander Kanavin wrote:
> On Fri, 29 May 2026 at 18:10, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>> This is likely a real QEMU 11.0 regression, but may not be in QEMU's
>> code itself. The QEMU 11.0 likely changed its display initialization to
>> be multi-threaded or reordered it, triggering a race condition in the
>> host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
>> solve the issue.
>>
>> This issue is different from the "glx: failed to create dri3 screen /
>> failed to load driver: vgem error" seen earlier, which was a missing GPU
>> driver issue on the host.
>>
>> If you have any detailed logs, please share with me and so I have more
>> contexts.
>
> It's the same issue, I assure you. Qemu 10.x prints nothing and simply
> starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
> (even though there's no wayland running on the build hosts), and then
> finally crashes, with the traceback that RP provided.
>
> I don't think it's a race condition, as the failure is deterministic,
> but I agree that something has changed in qemu's GL initialization
> sequence.
Cc'ing Marc-André & Akihiko
Context:
https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.camel@linuxfoundation.org/
> Unfortunately there are no more detailed logs than this. We've
> considered disabling this test, as accelerated rendering directly into
> gtk/sdl windows is tricky to support, complicated to reproduce (with
> regressions like this), and has limited use. I've promised RP to write
> up a proposal to oe-architecture, and I'll get to it :)
>
> Alex
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 6:35 ` ui: Regression calling eglInitialize() since v11.0.0 Philippe Mathieu-Daudé
@ 2026-06-05 8:10 ` Daniel P. Berrangé
2026-06-05 12:52 ` Alexander Kanavin
0 siblings, 1 reply; 28+ messages in thread
From: Daniel P. Berrangé @ 2026-06-05 8:10 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Akihiko Odaki, Marc-André Lureau, Alexander Kanavin,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
Quan.Sun, QEMU Developers
On Fri, Jun 05, 2026 at 08:35:13AM +0200, Philippe Mathieu-Daudé wrote:
> On 29/5/26 18:29, Alexander Kanavin wrote:
> > On Fri, 29 May 2026 at 18:10, Quan Sun via lists.openembedded.org
> > <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> > > This is likely a real QEMU 11.0 regression, but may not be in QEMU's
> > > code itself. The QEMU 11.0 likely changed its display initialization to
> > > be multi-threaded or reordered it, triggering a race condition in the
> > > host's Wayland/EGL/Mesa stack. Maybe setting SDL_VIDEODRIVER=x11 could
> > > solve the issue.
> > >
> > > This issue is different from the "glx: failed to create dri3 screen /
> > > failed to load driver: vgem error" seen earlier, which was a missing GPU
> > > driver issue on the host.
> > >
> > > If you have any detailed logs, please share with me and so I have more
> > > contexts.
> >
> > It's the same issue, I assure you. Qemu 10.x prints nothing and simply
> > starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
> > (even though there's no wayland running on the build hosts), and then
> > finally crashes, with the traceback that RP provided.
> >
> > I don't think it's a race condition, as the failure is deterministic,
> > but I agree that something has changed in qemu's GL initialization
> > sequence.
>
> Cc'ing Marc-André & Akihiko
>
> Context:
>
> https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.camel@linuxfoundation.org/
If it is an suspected regression between 10.2 and 11.0, then
I'd suggest someone who is able to reproduce the issue reliably
should do a 'git bisect' to narrow it down precisely.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 8:10 ` Daniel P. Berrangé
@ 2026-06-05 12:52 ` Alexander Kanavin
2026-06-05 13:07 ` Akihiko Odaki
0 siblings, 1 reply; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-05 12:52 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Philippe Mathieu-Daudé, Akihiko Odaki,
Marc-André Lureau, Richard Purdie, Mathieu Dubois-Briand,
openembedded-core, Quan.Sun, QEMU Developers
On Fri, 5 Jun 2026 at 10:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > It's the same issue, I assure you. Qemu 10.x prints nothing and simply
> > > starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
> > > (even though there's no wayland running on the build hosts), and then
> > > finally crashes, with the traceback that RP provided.
> > >
> > > I don't think it's a race condition, as the failure is deterministic,
> > > but I agree that something has changed in qemu's GL initialization
> > > sequence.
> >
> > Cc'ing Marc-André & Akihiko
> >
> > Context:
> >
> > https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.camel@linuxfoundation.org/
>
> If it is an suspected regression between 10.2 and 11.0, then
> I'd suggest someone who is able to reproduce the issue reliably
> should do a 'git bisect' to narrow it down precisely.
I've done additional testing, and I can confirm:
1. Reverting the following commit fixes the issue:
commit 52053b7e0a0e285ce3448b830053b05fb0a9b1a8
Author: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Date: Wed Mar 4 16:50:30 2026 +0000
ui/sdl2: Implement dpy dmabuf functions
2. Updating to 11.0.1 does not fix the issue. It includes a fix for a
different, but related problem:
674221887f ui/sdl2: Fix assumption of EGL presence at runtime
Note that the environment we run in is X11 without wayland, e.g. a
XTigervnc server that provides a X11 display.
Thanks,
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 12:52 ` Alexander Kanavin
@ 2026-06-05 13:07 ` Akihiko Odaki
2026-06-05 15:17 ` Alexander Kanavin
2026-06-05 15:21 ` Quan Sun
0 siblings, 2 replies; 28+ messages in thread
From: Akihiko Odaki @ 2026-06-05 13:07 UTC (permalink / raw)
To: Alexander Kanavin, Daniel P. Berrangé
Cc: Philippe Mathieu-Daudé, Marc-André Lureau,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
Quan.Sun, QEMU Developers, Pierre-Eric Pelloux-Prayer
On 2026/06/05 21:52, Alexander Kanavin wrote:
> On Fri, 5 Jun 2026 at 10:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> It's the same issue, I assure you. Qemu 10.x prints nothing and simply
>>>> starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
>>>> (even though there's no wayland running on the build hosts), and then
>>>> finally crashes, with the traceback that RP provided.
>>>>
>>>> I don't think it's a race condition, as the failure is deterministic,
>>>> but I agree that something has changed in qemu's GL initialization
>>>> sequence.
>>>
>>> Cc'ing Marc-André & Akihiko
>>>
>>> Context:
>>>
>>> https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.camel@linuxfoundation.org/
>>
>> If it is an suspected regression between 10.2 and 11.0, then
>> I'd suggest someone who is able to reproduce the issue reliably
>> should do a 'git bisect' to narrow it down precisely.
>
> I've done additional testing, and I can confirm:
>
> 1. Reverting the following commit fixes the issue:
>
> commit 52053b7e0a0e285ce3448b830053b05fb0a9b1a8
> Author: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
> Date: Wed Mar 4 16:50:30 2026 +0000
>
> ui/sdl2: Implement dpy dmabuf functions
>
> 2. Updating to 11.0.1 does not fix the issue. It includes a fix for a
> different, but related problem:
>
> 674221887f ui/sdl2: Fix assumption of EGL presence at runtime
>
> Note that the environment we run in is X11 without wayland, e.g. a
> XTigervnc server that provides a X11 display.
Cc'ing Pierre-Eric Pelloux-Prayer
My best bet is that SDL_HINT_VIDEO_X11_FORCE_EGL triggered the host
issue, but the stack trace cited above contradicts with that. I don't
exclude the possibility of a QEMU bug either.
Can you confirm the stack trace is from a run with X11? If so, the next
step would be to symbolize the stack trace. Otherwise, re-generating the
stack trace with X11 may help.
Regards,
Akihiko Odaki
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 13:07 ` Akihiko Odaki
@ 2026-06-05 15:17 ` Alexander Kanavin
2026-06-05 20:02 ` Alexander Kanavin
[not found] ` <18B647EA2CFF57AA.61226@lists.openembedded.org>
2026-06-05 15:21 ` Quan Sun
1 sibling, 2 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-05 15:17 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Marc-André Lureau, Richard Purdie, Mathieu Dubois-Briand,
openembedded-core, Quan.Sun, QEMU Developers,
Pierre-Eric Pelloux-Prayer
On Fri, 5 Jun 2026 at 15:08, Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
> > Note that the environment we run in is X11 without wayland, e.g. a
> > XTigervnc server that provides a X11 display.
>
> Cc'ing Pierre-Eric Pelloux-Prayer
>
> My best bet is that SDL_HINT_VIDEO_X11_FORCE_EGL triggered the host
> issue, but the stack trace cited above contradicts with that. I don't
> exclude the possibility of a QEMU bug either.
>
> Can you confirm the stack trace is from a run with X11? If so, the next
> step would be to symbolize the stack trace. Otherwise, re-generating the
> stack trace with X11 may help.
Please note the comment above about the environment - it is x11
without wayland, provided by xtigervnc.
I got a stack trace with symbols:
#0 0x00007ffff721b4f4 in pthread_mutex_lock () from
/home/akanavin/bitbake-builds/poky-master/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6
#1 0x00007ffff5a9a9e6 in wl_proxy_create_wrapper
(proxy=0x5555583f2940) at
../sources/wayland-1.25.0/src/wayland-client.c:2800
#2 0x00007ffff58bf994 in dri2_initialize_wayland_drm
(disp=0x555559548070) at
../sources/mesa-26.0.6/src/egl/drivers/dri2/platform_wayland.c:2680
#3 0x00007ffff58c0e7e in dri2_initialize_wayland
(disp=disp@entry=0x555559548070) at
../sources/mesa-26.0.6/src/egl/drivers/dri2/platform_wayland.c:3288
#4 0x00007ffff58b899d in dri2_initialize
(disp=disp@entry=0x555559548070) at
../sources/mesa-26.0.6/src/egl/drivers/dri2/egl_dri2.c:895
#5 0x00007ffff58abc3b in eglInitialize (dpy=<optimized out>,
major=0x0, minor=0x0) at
../sources/mesa-26.0.6/src/egl/main/eglapi.c:697
#6 0x00007ffff7cc77f5 in SDL_EGL_LoadLibrary
(_this=_this@entry=0x5555584054a0, egl_path=egl_path@entry=0x0,
native_display=0x5555583f2940, platform=platform@entry=0)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/video/SDL_egl.c:547
#7 0x00007ffff7cf4695 in X11_GLES_LoadLibrary
(_this=_this@entry=0x5555584054a0, path=path@entry=0x0)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/video/x11/SDL_x11opengles.c:56
#8 0x00007ffff7cf3ec8 in X11_GL_LoadLibrary (_this=0x5555584054a0,
path=<optimized out>)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/video/x11/SDL_x11opengl.c:270
#9 0x00007ffff7cd4734 in SDL_GL_LoadLibrary_REAL (path=path@entry=0x0)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/video/SDL_video.c:3493
#10 0x00007ffff7cd66c3 in SDL_CreateWindow_REAL (title=0x555556029e87
"", x=536805376, y=536805376, w=1, h=1, flags=42)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/video/SDL_video.c:1717
#11 0x00007ffff7c52688 in SDL_CreateWindow (a=a@entry=0x555556029e87
"", b=b@entry=536805376, c=c@entry=536805376, d=<optimized out>,
e=e@entry=1, f=f@entry=42)
at /home/akanavin/bitbake-builds/poky-master/build/tmp/work/x86_64-linux/libsdl2-native/2.32.10/sources/SDL2-2.32.10/src/dynapi/SDL_dynapi_procs.h:545
#12 0x0000555555be7b04 in sdl2_window_create
(scon=scon@entry=0x5555584240f0) at
../sources/qemu-11.0.0/ui/sdl2.c:106
#13 0x0000555555be92de in sdl2_gl_console_init (scon=0x5555584240f0)
at ../sources/qemu-11.0.0/ui/sdl2-gl.c:306
#14 0x0000555555be78e9 in sdl2_display_init (ds=<optimized out>,
o=0x555557124140 <dpy>) at ../sources/qemu-11.0.0/ui/sdl2.c:957
#15 0x0000555555b2938f in qemu_init_displays () at
../sources/qemu-11.0.0/system/vl.c:2689
#16 qemu_init (argc=<optimized out>, argv=<optimized out>) at
../sources/qemu-11.0.0/system/vl.c:3847
#17 0x0000555555892529 in main (argc=<optimized out>, argv=<optimized
out>) at ../sources/qemu-11.0.0/system/main.c:71
To me it seems like forcing EGL triggers those wayland code paths
where the crash happens.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 13:07 ` Akihiko Odaki
2026-06-05 15:17 ` Alexander Kanavin
@ 2026-06-05 15:21 ` Quan Sun
2026-06-05 19:55 ` [OE-core] " Alexander Kanavin
1 sibling, 1 reply; 28+ messages in thread
From: Quan Sun @ 2026-06-05 15:21 UTC (permalink / raw)
To: Akihiko Odaki, Alexander Kanavin, Daniel P. Berrangé
Cc: Philippe Mathieu-Daudé, Marc-André Lureau,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
QEMU Developers, Pierre-Eric Pelloux-Prayer
On 6/5/26 9:07 AM, Akihiko Odaki wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
> On 2026/06/05 21:52, Alexander Kanavin wrote:
>> On Fri, 5 Jun 2026 at 10:10, Daniel P. Berrangé <berrange@redhat.com>
>> wrote:
>>>>> It's the same issue, I assure you. Qemu 10.x prints nothing and
>>>>> simply
>>>>> starts, while qemu 11.x first tries glx/dri3 , then wayland/egl/vgem
>>>>> (even though there's no wayland running on the build hosts), and then
>>>>> finally crashes, with the traceback that RP provided.
>>>>>
>>>>> I don't think it's a race condition, as the failure is deterministic,
>>>>> but I agree that something has changed in qemu's GL initialization
>>>>> sequence.
>>>>
>>>> Cc'ing Marc-André & Akihiko
>>>>
>>>> Context:
>>>>
>>>> https://lore.kernel.org/openembedded-core/7da33301e8a0bae93a33695b4fd41f67a08e1b9f.camel@linuxfoundation.org/
>>>>
>>>
>>> If it is an suspected regression between 10.2 and 11.0, then
>>> I'd suggest someone who is able to reproduce the issue reliably
>>> should do a 'git bisect' to narrow it down precisely.
>>
>> I've done additional testing, and I can confirm:
>>
>> 1. Reverting the following commit fixes the issue:
>>
>> commit 52053b7e0a0e285ce3448b830053b05fb0a9b1a8
>> Author: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
>> Date: Wed Mar 4 16:50:30 2026 +0000
>>
>> ui/sdl2: Implement dpy dmabuf functions
>>
>> 2. Updating to 11.0.1 does not fix the issue. It includes a fix for a
>> different, but related problem:
>>
>> 674221887f ui/sdl2: Fix assumption of EGL presence at runtime
>>
>> Note that the environment we run in is X11 without wayland, e.g. a
>> XTigervnc server that provides a X11 display.
>
> Cc'ing Pierre-Eric Pelloux-Prayer
>
> My best bet is that SDL_HINT_VIDEO_X11_FORCE_EGL triggered the host
> issue, but the stack trace cited above contradicts with that. I don't
> exclude the possibility of a QEMU bug either.
>
> Can you confirm the stack trace is from a run with X11? If so, the next
> step would be to symbolize the stack trace. Otherwise, re-generating the
> stack trace with X11 may help.
>
> Regards,
> Akihiko Odaki
Hi Odaki,
I think I mentioned also in another email that this commit 52053b7e0a
("ui/sdl2: Implement dpy dmabuf functions") may have caused the issue,
which added the sdl2_set_hint_x11_force_egl() function:
static void sdl2_set_hint_x11_force_egl(void)
{
Display *x_disp = XOpenDisplay(NULL);
EGLDisplay egl_display;
if (!x_disp) {
return;
}
egl_display = eglGetDisplay((EGLNativeDisplayType)x_disp);
if (egl_display != EGL_NO_DISPLAY) {
SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
eglTerminate(egl_display);
}
XCloseDisplay(x_disp);
}
The above function probes whether EGL is available on the X display. If
eglGetDisplay() returns EGL_NO_DISPLAY (which can happen with llvmpipe on
certain VNC configurations, for example), the hint is never set, and SDL
falls back to GLX.
GLX then tries DRI3, finds only the vgem driver (no real GPU), and crashes.
In QEMU 10.2.0, this function didn't exist — SDL would use whatever GL
backend
was available (GLX with software rendering via llvmpipe worked fine because
it didn't attempt DRI3).
Possible Fixes could be: Setting the EGL hint unconditionally when on
X11 (remove the probe):
static void sdl2_set_hint_x11_force_egl(void)
{
#if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) &&
defined(CONFIG_X11)
SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
#endif
}
Thanks,
Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core] ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 15:21 ` Quan Sun
@ 2026-06-05 19:55 ` Alexander Kanavin
2026-06-05 22:18 ` Quan Sun
0 siblings, 1 reply; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-05 19:55 UTC (permalink / raw)
To: Quan.Sun
Cc: Akihiko Odaki, Daniel P. Berrangé,
Philippe Mathieu-Daudé, Marc-André Lureau,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
QEMU Developers, Pierre-Eric Pelloux-Prayer, Randy MacLeod
On Fri, 5 Jun 2026 at 17:21, Quan Sun via lists.openembedded.org
<Quan.Sun=windriver.com@lists.openembedded.org> wrote:
> I think I mentioned also in another email that this commit 52053b7e0a
> ("ui/sdl2: Implement dpy dmabuf functions") may have caused the issue,
> which added the sdl2_set_hint_x11_force_egl() function:
>
> static void sdl2_set_hint_x11_force_egl(void)
This is correct; I've confirmed it by adding a revert and re-running the test.
> The above function probes whether EGL is available on the X display. If
> eglGetDisplay() returns EGL_NO_DISPLAY (which can happen with llvmpipe on
> certain VNC configurations, for example), the hint is never set, and SDL
> falls back to GLX.
> GLX then tries DRI3, finds only the vgem driver (no real GPU), and crashes.
> In QEMU 10.2.0, this function didn't exist — SDL would use whatever GL
> backend
> was available (GLX with software rendering via llvmpipe worked fine because
> it didn't attempt DRI3).
> Possible Fixes could be: Setting the EGL hint unconditionally when on
> X11 (remove the probe):
>
> static void sdl2_set_hint_x11_force_egl(void)
> {
> #if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) &&
> defined(CONFIG_X11)
> SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
> #endif
>
> }
All of this is yet more AI-generated nonsense, and none of it is true.
Quan, I appreciate you want to help, but please do not copy paste AI
slop without carefully checking its claims first. And if you do, make
it clear that you are providing 'AI advice'.
Otherwise it only multiplies confusion, and damages your own reputation.
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 15:17 ` Alexander Kanavin
@ 2026-06-05 20:02 ` Alexander Kanavin
[not found] ` <18B647EA2CFF57AA.61226@lists.openembedded.org>
1 sibling, 0 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-05 20:02 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Daniel P. Berrangé, Philippe Mathieu-Daudé,
Marc-André Lureau, Richard Purdie, Mathieu Dubois-Briand,
openembedded-core, Quan.Sun, QEMU Developers,
Pierre-Eric Pelloux-Prayer
On Fri, 5 Jun 2026 at 17:17, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> Please note the comment above about the environment - it is x11
> without wayland, provided by xtigervnc.
...
> To me it seems like forcing EGL triggers those wayland code paths
> where the crash happens.
I think I found a way to trigger this in a regular wayland desktop
(with XWayland). You need to unset WAYLAND_DISPLAY:
$ WAYLAND_DISPLAY= ../bin/qemu-system-x86_64 -display sdl,gl=on
Segmentation fault WAYLAND_DISPLAY= ../bin/qemu-system-x86_64
-display sdl,gl=on
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core] ui: Regression calling eglInitialize() since v11.0.0
2026-06-05 19:55 ` [OE-core] " Alexander Kanavin
@ 2026-06-05 22:18 ` Quan Sun
0 siblings, 0 replies; 28+ messages in thread
From: Quan Sun @ 2026-06-05 22:18 UTC (permalink / raw)
To: Alexander Kanavin
Cc: Akihiko Odaki, Daniel P. Berrangé,
Philippe Mathieu-Daudé, Marc-André Lureau,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
QEMU Developers, Pierre-Eric Pelloux-Prayer, Randy MacLeod
On 6/5/26 3:55 PM, Alexander Kanavin wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, 5 Jun 2026 at 17:21, Quan Sun via lists.openembedded.org
> <Quan.Sun=windriver.com@lists.openembedded.org> wrote:
>> I think I mentioned also in another email that this commit 52053b7e0a
>> ("ui/sdl2: Implement dpy dmabuf functions") may have caused the issue,
>> which added the sdl2_set_hint_x11_force_egl() function:
>>
>> static void sdl2_set_hint_x11_force_egl(void)
> This is correct; I've confirmed it by adding a revert and re-running the test.
>
>> The above function probes whether EGL is available on the X display. If
>> eglGetDisplay() returns EGL_NO_DISPLAY (which can happen with llvmpipe on
>> certain VNC configurations, for example), the hint is never set, and SDL
>> falls back to GLX.
>> GLX then tries DRI3, finds only the vgem driver (no real GPU), and crashes.
>> In QEMU 10.2.0, this function didn't exist — SDL would use whatever GL
>> backend
>> was available (GLX with software rendering via llvmpipe worked fine because
>> it didn't attempt DRI3).
>> Possible Fixes could be: Setting the EGL hint unconditionally when on
>> X11 (remove the probe):
>>
>> static void sdl2_set_hint_x11_force_egl(void)
>> {
>> #if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) &&
>> defined(CONFIG_X11)
>> SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
>> #endif
>>
>> }
> All of this is yet more AI-generated nonsense, and none of it is true.
>
> Quan, I appreciate you want to help, but please do not copy paste AI
> slop without carefully checking its claims first. And if you do, make
> it clear that you are providing 'AI advice'.
>
> Otherwise it only multiplies confusion, and damages your own reputation.
>
> Alex
Hi Alex,
I think one of the purposes of this kind of email exchanges is for
technical discussions and exchanges of ideas to resolve any possible
technical issues in the communities, and there is no need to have any
bias on the way how other people work or dictate what tools they use.
Based on my past years of working experiences on virtio-gpu/mesa/drm,
I'm pointing out a possible scenario in the following call in the
function of "void sdl2_set_hint_x11_force_egl(void)":
egl_display = eglGetDisplay((EGLNativeDisplayType)x_disp);
It could occur that the above call returns EGL_NO_DISPLAY or it crashes
before it even returns for the specific setup.
Thanks,
Quan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [OE-core] ui: Regression calling eglInitialize() since v11.0.0
[not found] ` <18B647EA2CFF57AA.61226@lists.openembedded.org>
@ 2026-06-10 10:36 ` Alexander Kanavin
0 siblings, 0 replies; 28+ messages in thread
From: Alexander Kanavin @ 2026-06-10 10:36 UTC (permalink / raw)
To: alex.kanavin
Cc: Akihiko Odaki, Daniel P. Berrangé,
Philippe Mathieu-Daudé, Marc-André Lureau,
Richard Purdie, Mathieu Dubois-Briand, openembedded-core,
Quan.Sun, QEMU Developers, Pierre-Eric Pelloux-Prayer
On Fri, 5 Jun 2026 at 22:02, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Fri, 5 Jun 2026 at 17:17, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> > Please note the comment above about the environment - it is x11
> > without wayland, provided by xtigervnc.
>
> ...
>
> > To me it seems like forcing EGL triggers those wayland code paths
> > where the crash happens.
>
> I think I found a way to trigger this in a regular wayland desktop
> (with XWayland). You need to unset WAYLAND_DISPLAY:
>
> $ WAYLAND_DISPLAY= ../bin/qemu-system-x86_64 -display sdl,gl=on
> Segmentation fault WAYLAND_DISPLAY= ../bin/qemu-system-x86_64
> -display sdl,gl=on
I filed a ticket for this with the most important findings:
https://gitlab.com/qemu-project/qemu/-/work_items/3540
Alex
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2026-06-10 10:36 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-28 20:26 [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan.Sun
2026-05-29 12:42 ` Mathieu Dubois-Briand
2026-05-29 14:44 ` Quan Sun
2026-05-29 15:23 ` Alexander Kanavin
2026-05-29 15:49 ` Richard Purdie
2026-05-29 16:10 ` Quan Sun
2026-05-29 16:29 ` Alexander Kanavin
2026-05-29 16:47 ` Quan Sun
2026-05-29 17:18 ` Alexander Kanavin
2026-05-29 18:13 ` Quan Sun
2026-05-29 18:43 ` Alexander Kanavin
2026-06-05 6:35 ` ui: Regression calling eglInitialize() since v11.0.0 Philippe Mathieu-Daudé
2026-06-05 8:10 ` Daniel P. Berrangé
2026-06-05 12:52 ` Alexander Kanavin
2026-06-05 13:07 ` Akihiko Odaki
2026-06-05 15:17 ` Alexander Kanavin
2026-06-05 20:02 ` Alexander Kanavin
[not found] ` <18B647EA2CFF57AA.61226@lists.openembedded.org>
2026-06-10 10:36 ` [OE-core] " Alexander Kanavin
2026-06-05 15:21 ` Quan Sun
2026-06-05 19:55 ` [OE-core] " Alexander Kanavin
2026-06-05 22:18 ` Quan Sun
2026-05-29 15:52 ` [OE-core][PATCH] qemu: upgrade 10.2.0 -> 11.0.0 Quan Sun
2026-05-29 16:17 ` Alexander Kanavin
2026-06-02 16:57 ` Ross Burton
2026-06-02 19:25 ` Quan Sun
2026-06-02 19:44 ` Alexander Kanavin
[not found] ` <18B55B33A6799835.3712505@lists.openembedded.org>
2026-06-04 11:09 ` Alexander Kanavin
2026-06-04 15:58 ` Richard Purdie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.