Kernel & Embedded News: Linux 7.3 Merge Window; QEMU 11.1 Released

Linux 7.2 shipped on 16 August and the 7.3 merge window is now open. Queued for 7.3 are an SMP rework that reduced scheduling latency by about 90% in Bytedance's fleet testing, and BPF-driven interpreter selection for binfmt_misc. Away from the kernel, QEMU 11.1 was released on 11 August with UFS 4.1 emulation and RISC-V big-endian support, and Radxa introduced two Qualcomm-based SoMs with availability commitments running to 2029 and 2036.

With 7.2 out, this edition looks forward. The 7.3 merge window opened on Monday, and the early pull requests already indicate the direction of the cycle. Alongside the kernel, there is a significant QEMU release and new Qualcomm-based hardware for edge AI work.

In this edition

Linux 7.3 merge window opens — 7.2 shipped on 16 August; the two-week 7.3 merge window is under way, with hardware enablement, scheduler work, and several old-driver removals queued. (Phoronix)
SMP rework targets IPI-related latency spikes — Bytedance patches let tasks stay preemptible while waiting for remote CPUs, cutting high-priority task latency from about 17ms to about 1.5ms in their fleet. (Phoronix)
binfmt_misc gains programmatic matching and BPF hooks — Christian Brauner's VFS pull for 7.3 lets the interpreter for a binary be computed per exec, including by an attached BPF program. (pull request)
QEMU 11.1 released — UFS Write Booster and defragmentation emulation from the UFS 4.1 specification, RISC-V big-endian support, and user-mode emulation improvements. (changelog)
Radxa introduces two Qualcomm-based SoMs — the rCore-Q8280 (Snapdragon 8cx Gen 3) and rCore-Q6490 (Dragonwing QCS6490) target edge AI, with availability committed to 2029 and 2036 respectively. (LinuxGizmos)

Linux 7.3 merge window opens: what is queued

Linus Torvalds released Linux 7.2 on Sunday 16 August, noting that the final week of fixes was again larger than he would have liked. We covered what 7.2 changes for embedded teams in a separate post, so here the focus is the 7.3 merge window, which opened on Monday and runs for about two weeks. The first release candidate is expected around 30 August, with the stable release in late October.

The queue is broad. On the CPU side there is a KCFI optimisation that benefits older Intel processors using control-flow integrity, better cluster load balancing for Intel hybrid P-core/E-core parts, and per-core dynamic EPP for AMD's P-State driver with Zen 6. On the Arm side, initial device tree support for Apple M3 Pro, Max, and Ultra arrives, though it only boots to a console at this stage. The Qualcomm MSM DRM driver adds Adreno 704 and Adreno 722 GPU support, which matters for anyone tracking mainline graphics on recent Snapdragon parts.

The removals deserve equal attention. Old SGI drivers are being dropped on security grounds, some legacy Moxa serial card drivers are going, and the FreeVxFS and EFS filesystems are being retired. Maintainers are removing old code more aggressively than they used to, and the cost falls on products that quietly depend on it.

One planning note: Phoronix expects either 7.3 or 7.4 to become this year's LTS kernel, depending on whether the remaining cycles finish on time. That designation is not yet made.

How to use the 7.3 cycle

Scan the merge-window pulls for your SoC's subsystems now rather than reading release notes in October. If your product uses any driver on the removal list, plan a migration or pin your kernel deliberately, with a written record of why. Teams selecting a base kernel for a new product should wait for the LTS designation on kernel.org before committing; guessing between 7.3 and 7.4 today gives no advantage.

SMP rework targets IPI-related latency spikes

The SMP pull request for 7.3, sent by Thomas Gleixner on 17 August, contains a change worth understanding in detail. The smp_call_function family of kernel functions has kept preemption disabled for the whole operation, including the wait for remote CPUs to finish executing the IPI function. When a target CPU is slow to respond, that wait extends, and scheduling latency grows with the number of remote CPUs involved.

This is not an obscure path. On x86_64, TLB flushes are performed through IPIs, so process exit and reclamation of process-mapped pages can end up waiting on multiple IPI operations with preemption off. Bytedance engineers hit this in production with latency-sensitive workloads and reworked the code: a per-task CPU mask now tracks which CPUs a task is waiting for, which makes the wait state task-local and allows preemption to be re-enabled before the wait begins.

The numbers in the pull request are specific. Fleet-measured latency for high-priority tasks caused by SMP function calls dropped from about 17ms to about 1.5ms, a reduction of roughly 90%, and their DPDK testing showed a similar improvement in P99 latency. A preemption-disabled window that stretches with remote CPU count is exactly the class of latency source that PREEMPT_RT alone does not remove, which is why this rework matters beyond the scheduler team.

The pull is awaiting action from Linus Torvalds and is expected to land during this merge window; it is queued work, not yet in mainline.

What it means for real-time and dataplane teams

If you ship latency-sensitive systems on many-core hardware, put 7.3-rc on a test rig once the pull lands and re-run your cyclictest and application-level latency measurements. Pay particular attention if your workload does frequent process teardown or memory reclaim on x86_64, since those paths wait on TLB-flush IPIs. Record before/after numbers; a change this deep in the SMP core is also the kind you want evidence about, not assumptions.

binfmt_misc gains programmatic matching and BPF hooks

binfmt_misc is the mechanism that lets Linux execute non-native binaries transparently — Windows EXE files through Wine, JAR files through the Java runtime, and, most relevant to embedded engineers, foreign-architecture binaries through qemu-user during cross-development. Until now, a registered format carried a fixed interpreter string decided at registration time.

Christian Brauner's VFS pull request for 7.3 changes that. The format registry is extended so a binary type can be matched programmatically and the interpreter computed per exec. BPF programs can be attached to binfmt_misc entries to choose the execution environment on a per-binary basis. The stated motivation includes relocatable binaries for NixOS and similar systems, where the dynamic loader is found relative to the binary rather than at a fixed path.

The pull also adds two dispatch modes. Transparent dispatch has the interpreter load the binary through AT_EXECFD while the argument vector, /proc/pid/cmdline, and mm->exe_file keep naming the binary rather than the interpreter — which fixes, among other things, gdb tripping over mismatched AT_ENTRY and AT_PHDR values on interpreted binaries. Loader substitution executes the binary natively and changes only the interpreter.

The LWN discussion around the patches asked a fair question: does everything need BPF? One camp sees each new BPF attachment point as added complexity and attack surface. The other argues that a single well-audited in-kernel programmable mechanism is better than accumulating one-off special cases, and that subsystems tend to grow BPF support eventually anyway, as seccomp did. Both positions are reasonable; the second is prevailing in practice.

What it means for cross-development

Build infrastructure that relies on qemu-user — Yocto and Buildroot postinstall emulation, cross-architecture container builds — stands to gain the most. Transparent dispatch removes the argv and /proc mismatches that break some tooling under emulation today. Nothing changes until 7.3 ships and userspace grows support, so the current action is to note the capability and watch how qemu and the distributions adopt it.

QEMU 11.1 released with UFS 4.1 emulation and RISC-V additions

QEMU 11.1 was released on 11 August. No single feature dominates the release, but several additions are directly useful for embedded and kernel work.

The UFS device model now emulates Write Booster and Host Initiated Defragmentation from the UFS 4.1 specification. UFS is the standard storage interface on phone-class and automotive SoCs, and driver paths for features like Write Booster are awkward to exercise on hardware, where the feature's behaviour depends on device state you cannot easily control. Emulation makes those paths testable in CI.

On the RISC-V side, 11.1 adds support for new extensions including Zvfbfa and, notably, big-endian support. Big-endian RISC-V is a niche, but if your codebase claims endian-independence, you now have another readily available big-endian target to prove it on without hunting for legacy hardware. Arm emulation gains a set of newer CPU architectural features, and user-mode emulation — the qemu-user side that cross-build systems depend on — receives a round of improvements.

Checking what you are running is quick:

raghu@techveda.org:~$ qemu-system-aarch64 --version
raghu@techveda.org:~$ ls /proc/sys/fs/binfmt_misc/

The second command lists the binary formats currently registered with binfmt_misc, including any qemu-user handlers, which connects this item to the binfmt_misc work above: both ends of that pipeline are moving this month.

How to use it

Upgrade the QEMU in your CI images deliberately rather than waiting for your distribution to do it. Storage-driver teams should look at the UFS 4.1 emulation for regression tests that previously required hardware. If you maintain portable system code, add a big-endian RISC-V build to the test matrix and review what fails.

Radxa introduces two Qualcomm-based SoMs for edge AI

Radxa has announced two system-on-modules built on Qualcomm silicon, covered by LinuxGizmos on 9 August. The rCore-Q8280 uses the Snapdragon 8cx Gen 3 (SC8280XP): eight Kryo cores (four Prime at up to 3.0GHz, four Gold at 2.4GHz), an Adreno 690 GPU, a 29+ TOPS AI engine, up to 32GB of LPDDR4X on a 128-bit interface, and nine PCIe Gen3 lanes, on a 50×80mm module. The smaller rCore-Q6490 uses the Dragonwing QCS6490: a Kryo 670 CPU, Hexagon 770 AI engine rated at up to 12 dense TOPS, up to 16GB LPDDR5, and five 4-lane MIPI-CSI camera interfaces through the Spectra 570L ISP, on a 42×36mm module.

Two details matter more than the TOPS figures. First, the availability commitments: Radxa states the rCore-Q8280 will remain available until at least June 2029 and the rCore-Q6490 until at least June 2036. A ten-year availability window on a camera-heavy edge AI module is a serious commitment for industrial product planning. Second, the software lists differ: the Q6490 lists Yocto support, while the Q8280 lists desktop-style distributions, which suggests different BSP maturity paths for the two modules.

Hardware availability and kernel support are separate lifetimes, though. A module you can buy in 2034 still needs a kernel you can patch in 2034, and that depends on the BSP model — vendor kernel versus upstream — not on the supply commitment. We examined how SoC kernel support quietly lapses in an earlier post, and the same test applies here. Pricing and retail availability for both modules have not yet been announced.

How to evaluate them

Before designing either module in, get answers in writing: which kernel version the BSP ships, who publishes security updates and for how long, and what the upstream story is for the SoC. Check the licensing and distribution terms for the camera ISP and AI runtime userspace, which on Qualcomm parts often constrain product plans more than the hardware does. Compare against i.MX and TI equivalents on documentation and long-term kernel support, not only on TOPS per dollar.