Kernel & Embedded News: Syscall Entry Reworked for 7.3; KVM MMU Split

A reworked system-call entry path and KVM’s kvm_mmu split are queued for Linux 7.3, while a Reserved THP RFC and a Raspberry Pi 5 IOMMU driver are still under review.

This edition is forward-looking. Rather than what 7.2 delivers, it covers work that is proposed, queued, or under review for the releases after it. For this kind of edition the status of each item matters as much as the feature itself, so I state where each one actually stands and what, if anything, is worth doing now.

In this edition

• The system-call entry path is being reworked for Linux 7.3. A cleanup that fixes stack-randomization ordering across architectures (Phoronix).
• KVM’s kvm_mmu is being split apart for Linux 7.3. The “KVM chainsaw” divides an overloaded structure into three (Phoronix).
• “Reserved THP” is proposed as an RFC. An attempt to combine the guarantees of HugeTLB with the flexibility of transparent huge pages (Phoronix).
• A Raspberry Pi 5 IOMMU driver is under review for mainline. The BCM2712 IOMMU is being upstreamed, starting with the display controller (Phoronix).

A reworked system-call entry path, queued for Linux 7.3

Veteran kernel developer Thomas Gleixner has prepared a rework of the kernel’s system-call entry handling that is expected to land in Linux 7.3. It began from a proposed change to how the kernel handles system-call numbers and grew into a broader cleanup. The patches are already sitting in the tip tree’s core/entry branch, which is the normal staging point before a 7.3 merge-window submission.

The substance is in how architectures apply kernel stack randomization. The randomization offset must be added only after the kernel has established proper state on entry from user mode, and Gleixner found that PowerPC was doing it incorrectly and that several other architectures applied it later than ideal. His series introduces an add_random_kstack_offset_irqsoff() variant that avoids per-CPU access overhead in the interrupt-disabled path, moves the randomization to the earliest correct point, and converts every architecture that uses the generic entry code to the same scheme. He also has the syscall-permission helpers return a boolean and cleans up some long-standing x86 entry oddities.

Gleixner states there are no intended functional changes; system-call-heavy micro-benchmarks show a small gain and the x86_64 entry code is slightly smaller. Do not treat this as something to act on directly. Its value for practitioners is different: the entry path is one of the most security-sensitive and least-forgiving parts of the kernel, and stack randomization is a real exploitation-mitigation control, so having it applied consistently and at the right point across architectures is a quiet improvement to the security baseline. If you carry an out-of-tree architecture port or custom entry code, this is the change to read closely before you rebase onto 7.3, because the scheme it standardises is the one your port will be expected to follow.

The “KVM chainsaw” splits kvm_mmu apart, queued for Linux 7.3

KVM maintainer Paolo Bonzini has merged a large refactor, informally called the “KVM chainsaw”, into KVM’s next branch, from where it is expected to reach the Linux 7.3 merge window that opens in the second half of August. It targets kvm_mmu, which Bonzini calls a “god data structure” doing three jobs at once: describing the guest page-table format, walking the guest page tables, and building the shadow page tables.

The series divides that into three clearer pieces: kvm_pagewalk for the page-table walker, kvm_mmu retaining the page-table building role, and kvm_page_format for operating on existing page-table entries. Beyond the cleanup it reduces a long-standing naming confusion between guest_mmu and nested_mmu, and the final patch shows the refactor also opens the door to a new capability: supporting shadow page-table entries where supervisor and user execute permissions differ, exposed through memory attributes.

This is maintainer-facing internals rather than a feature most product teams consume directly. It matters if you run virtual machines on x86 or Arm server and edge platforms, or if you carry local KVM patches, because a clearer MMU path reduces the class of subtle shadow-paging bugs that are expensive to diagnose. There is nothing to do today. Flag it if you maintain out-of-tree KVM changes, since a structural rename of this size will require reworking any patches that touch the MMU when you move to 7.3.

“Reserved THP” — an RFC to merge the strengths of HugeTLB and THP

Bytedance engineer Qi Zheng has sent a request-for-comments series proposing a feature called Reserved THP. It is worth stressing the status: this is an RFC, an opening position for discussion, not something queued for a release. The kernel has had two large-page mechanisms that each give up something. HugeTLB offers reservations and guaranteed allocation from a reserved pool but does not support swap. Transparent huge pages (THP) integrate tightly with core memory management and can be swapped, but offer no reservation and no guarantee that an allocation succeeds.

The proposal is for huge pages that can be reserved like HugeTLB, consumed deliberately through interfaces such as madvise() rather than by ordinary allocation, while remaining THP and therefore able to swap. The motivating case is a hot-upgrade pattern where a process must temporarily reserve double its huge-page memory, most of which is then wasted; being able to reclaim cold reserved pages through swap would remove that waste.

Unifying HugeTLB and THP has been discussed for years without resolution, so treat this as a direction to watch, not a decision. For teams building memory-heavy workloads on Linux — databases, in-memory caches, and increasingly on-device AI on constrained hardware — huge-page behaviour has a direct effect on latency and footprint. If that is you, following this thread is useful input for capacity planning, but it is far too early to design around. This is the kind of core memory-management topic we spend time on in our systems and kernel courses at TECH VEDA, precisely because the trade-off between reservation and flexibility is easy to get wrong in production.

A Raspberry Pi 5 IOMMU driver, under review for mainline

Developer Daniel Drake has posted a first version of a mainline driver for the Broadcom BCM2712 IOMMU used on the Raspberry Pi 5, and it is now under code review. The Pi 5 has been shipping for over two and a half years, but its IOMMU has lived only in Raspberry Pi’s downstream tree; this series adapts that work for upstream, starting by wiring the IOMMU to the display controller for efficient graphics-memory management.

The upstreaming does the usual work of turning a vendor driver into something mainline will accept. It moves page-table management onto the kernel’s generic page-table code (generic_pt), renames the device-tree properties to standards-compliant names such as brcm,iova-window and brcm,iommu-cache while keeping compatibility with firmware already in the field, and drops a DMA offset workaround that needs a proper fix later. One detail worth noting for embedded engineers: the IOMMU works only with 4 KB pages, so on the Pi 5’s default 16 KB-page kernel each page-table page wastes 12 KB, which the author plans to address in follow-up work.

Because the Raspberry Pi is so common in prototypes, labs, and low-volume products, mainline IOMMU support has real practical value: it is what lets you use the platform’s DMA-capable devices with proper memory isolation instead of relying on the downstream kernel. If your product tracks a vendor tree today, this is a good example of why upstreaming matters, since it reduces the long-term maintenance burden of carrying out-of-tree patches. Once the driver lands you can confirm the hardware groups are visible in the usual place:

raghu@techveda.org:~$ ls /sys/kernel/iommu_groups/
0  1  2  3

For now the driver is still in review, so this is one to track rather than deploy. It is a clean illustration of the path a real embedded driver takes from a vendor branch to the mainline kernel.

References

• Reworked System Call Entry Handling Slated For Linux 7.3 — Phoronix
• Gleixner’s syscall entry rework series — lore.kernel.org
• “KVM Chainsaw” Expected To Hit Linux 7.3 — Phoronix (with Bonzini’s merge message)
• Reserved THP Feature Proposed For Linux — Phoronix
• Raspberry Pi 5 IOMMU Driver Being Worked On For Mainline — Phoronix
• BCM2712 IOMMU driver v1 cover letter — lore.kernel.org

— Raghu Bharadwaj