To see the importance of this API, we must know the systems we have and the problem it solves.

Here is a limited view of how displays are managed on linux:

In most cases the compositor works a lot like a press. it will take all the elements that it wants to show, flatten it into an image, and sends it to be displayed. Under some circumstances, the Compositor can be bypassed, like when playing a game fullscreen, but normally, it will be processing the frame.

This is where our issues start.

Modern screens have the ability to process some instructions themselves. They also have more possibilities on the amount or detail of colors shown.

Under our current system, an HDR display would require the compositor to send a compatible HDR frame that has been fully processed by the compositor. That is without using the optimized circuits of the screen.

This makes the job of the compositor devs way more complicated as they have to implement a lot of redundant code for different features that the display or user may require.

The solution for this is the DRM Color Pipeline API.

It works by creating standard operations called drm_colorop.

These operations can be chained together in a list and used on different part of a frame. They are processed either by the screen hardware or vendor specific DRM code.

At initialization, the compositor will test multiple list of operations to see which ones are compatible with the screen hardware and vendor specific DRM code, allowing it to use the most complete one.

This allows the processing of the frame to be standardize and removes the redundant code that was once needed to process HDR frames.^[32]

This also allows a program to set its own rule for how to process its frames.

Lets think of an image editor. It might need to have some specific processing in order to display the correct colors. The compositor will now be able to act as a pass-through allowing the image editor to set its own policies, unbothered by any other processing.

Not all DRM drivers have the capability to use the Pipeline, for now only AMDGPU and the generic Virtual KMS (VKMS) drivers have implemented it. On the compositor front, Valve's Gamescope, KDE KWin and Wayland's Weston implementations are being worked on.^[33]

Some operations require the Kernel to use pointers that have been provided by the User-Space.

These pointers are deemed 'unsafe' and required to be tested by the CPU. Even if the CPU is capable of knowing if a given address should be accessible by the userspace, Speculation doesn't, which means that we need to prevent the speculation from running a malicious pointer.

Remember speculation is the ability of your CPU to fetch instructions before they are actually needed. For example a JMP instruction with a malicious address might leak Kernel memory. The speculation hardware will essential guess an address and this guess might be poisoned.

The kernel usually use barriers to prevent speculation from fetching any address, at the cost of slowing down execution.

This release presents a new solution, but to understand it, we will need to understand how to kernel organizes memory.

When starting, each program is granted its own virtual address space.

This address space is divided in multiple sections. Smaller addresses are used for the userspace and higher addresses are reserved for the Kernel.

_Important note_ The userspace will always be in the lower half as the kernel space will always be in the upper half.

This means that by looking at the most important bit from an address we would be able to know if an address is valid or not.

Now, you might be tempted to use an if to test the most important bit, but that would be a mistake. IFs introduce branching which is undesirable in Critical code.

Lets do a bit of X86(64) assembly to understand the solution:

SAR (1010 0010) 7 => 1111 1111 (Shift Arithmetic Right) x(ARCH bit-1)

SHR (1111 1111) 1 => 0111 1111 (Shift Logical Right)

NOT (0111 1111) => 1000 0000

AND (1000 0000) (1010 0010) => 1000 0000

valid:

SAR (0010 0010) 7 => 0000 0000

SHR (0000 0000) 1 => 0000 0000

NOT (0000 0000) => 1111 1111

AND (1111 1111) (0010 0010) => 0010 0010

The equivalent assembly was added for X86, Arm, Arm64, Risc-V, PowerPC, S390 Bringing this optimization to most architecture^[21]

As seen in the last kernel vids, Most architectures and vendors are trying to make their products more secure on the confidential computing front.

AMD-SEV, Intel-TDX, ARM-CCA all have different ways of making sure that a malicious host cannot access the data of a guest.

PCIe has always been outside of the Trust Compute Boundary of these technologies.

Now lets take a moment to understand how communication between PCIe devices and Secured VMs normally happens.

In a Secured VM, the memory of the VM is encrypted, this removes our ability to ask a PCIe device to read the VM's memory directly through DMA.

This forces us to use a Software IO Virtualization of the PCIe device.

The host will supply the VM with a shared buffer that will then be used with the PCIe device.

This is slow and untrusted. In the event that the PCIe device; say a GPU or an accelerator; doesn't have encryption/decryption capabilities, it would also force us to leak the information that we send to the buffer, the information we want to process.

In any other circumstances, we would assume that each vendor would create their own solutions to this problem.

But they did not.

PCIe 7.0 Released in June 2025 renewed the commitment to a universal solution.

Lets get into it:

The new release brings multiple agreed upon soup of acronyms:

MAKE A FUCKING ACRONYM COUNTER

Lets see in practice how these concepts are implemented.

Take a VM secured by a Trusted Execution Environment (TEE) .

The TEE would upon detecting compatible hardware make it available to the VM.

No permission or access is given to the PCIe device without the VM's approval.

The VM can then request to the TEE to get access to a Function of the PCIe device.

The TEE will than proceed to create an IDE connection with the PCIe device, Encrypting its communication and allowing the VM access to the function.

Subsequent transfers would be done using the CMA-SPDM standard through the DOE format.

This solves 3 fundamental issues with PCIe communications when using Confidential VMs:

PCIe 7.0 also allows, with the VM's authorization, DMA operations directly to the VM's memory. Increasing performance.

The standard also outline how a PCIe device should be divided in Functions accessible by a TEE Device Interface (TDI).

Let's think of a 4 Port Network card. Each port is a Function and is linked to a TDI. A VM may grant the TDI DMA access to it's memory or send packets directly through the card.

These communications are all encrypted under the IDE connection, away from the host. The TEE along with the TDI ensures that one VM cannot interfere with another.

The skeptics among you might say:

What is the point of all of this if the host uses a fake PCIe Device?

The standard got you covered.

Upon connection with a TDI, the TDI will transfer a signed version of their internal measurement, firmware version and other hardware information. The signature can be verified against the vendor-supplied certificate and the measurement can be tested to confirm that the hardware wasn't altered.

This ensures full confidentiality while relying only on the makers of your hardware.

Now, back to the kernel.

From this standard, a new subsystem is born:

The PCI Trusted Execution Environment Security Manager (TSM)

The code handling the IDE connection and the framework for initiating secured connection was added to the kernel.

For this release, only the AMD SEV-TIO (Trusted IO) implementation was included, but Intel TDX Connect and ARM-CCA are currently waiting in the new TSM tree: kernel/git/devsec/tsm.git

The Devs have given us a maturity map, we still have a long way to go, but i'll keep you updated.^[16]

Sources:

Intel's view on confirming devices^[20]

TDX Connect ^[17]

AMD SEV-TIO^[18]

Patch^[19]

Intel LASS Has now been merged.

Intel Linear Address Space Separation (LASS) is an hardware feature that defends against side channel attack. When Fetching an address, the CPU will do what we call a page walk, This page walk will happen even if we don't have the permission to read the underlying address. This can take more or less time depending on what is the memory used for or if the memory is cached.

As we know, in a 64 bit systems, the kernel space will be in the upper half of the virtual address space.

Taking advantage of that fact, a CPU with LASS enabled will refuse to let you do the page walk on a memory address that is on the upper part of your memory.

This prevents an attacker from getting timings information that might leak the underlying use of the memory.^[25]

-Intel Glob blob flob thing, who cares^[26]

-Intel SGX same as above ^[27]

-Optimized NUMA Distances For Intel GNR CWF^[31]

AMD Smart Data Cache Injection (SDCI) has been added to the kernel.

Normally, if you wanted to get data from a PCIe device to the L3 cache of your CPU, you would have to first put it in ram, than you could get it to the L3. The new SDCI feature from AMD allows us to get that data from PCIe without copying it into ram, saving bandwidth.^[28]

-Update on RAS (Reliability, Availability and Serviceability), more bits unlocked for diag....^[28]

Arm MPAM Support.

Arm MPAM (Memory System Resource Partitioning and Monitoring) is a feature since ARMv8.4 for managing shared memory resources like the CPU caches, memory bandwidth, and other resources. MPAM Is intended to help the partition and monitoring for ARM64 servers with multi-user virtual machines to ensure no single user disproportionately utilizes too many system resources.^[15]

Beginning implementation for LoongArch32, yes LoongArch has always been a 64bit Architecture but the work to implement a 32bit version has begun.

The GCC compiler code for the new LA32 Application Binary Interface (ABI) is currently being reviewed.

2 versions of the new Arch exist:

For now, the work needed to make this arch a reality is not done, More fixes on drivers need to be implemented before it can work.^[11]

HOTPLUG_PARALLEL support.

So Architectures in the kernel like X86 and MIPS have the capability to bring Secondary cores online Asynchronously with HOTPLUG_PARALLEL support.^[13]

Risc-V was close to having support but was missing a few key ingredients for it:

1) Providing RISC-V specific arch_cpuhp_kick_ap_alive()

2) Calling cpuhp_ap_sync_alive() from smp_callin()^[12]

Certified UNIT: Anup Patel from Ventana Micro (a Qualcomm subsidiary) Fixed these missing features and enable HOTPLUG_PARALLEL on Risc-V which grants faster enabling of secondary cores withing an SoC.

Zicbop (Prefetch operations) Now available to userspace^[13]

-Zalasr RISC-V ratified ISA extension^[13]

Maybe read more

?- Fixes A Thundering Herd Problem For Big NUMA Servers^[22]

EXT4

NTFS

HFS

-F2FS

-NFS

Full Per-CPU BIO Caching is now the Default.

Lets split this to understand this change.

When talking about BIO we need to keep in mind that the memory address used will be a physical address.

The BIO is meant to be used with DMA which will allow us to get data from the place it currently is in memory to the disk and back without copying it to a buffer.

The benchmarks currently show a small gain in performance with little to no regression.^[43]

Last release, we talked about 2-way interleaved SHA-256 hashing that was added to the crypto library.

We also predicted that it would be applied to DM-VERITY, which it now is.

So DM-VERITY is a device mapper that provides encryption at the block device level.

It now uses the Crypto library included in the kernel, thus it enjoys its optimizations, remember the 2x performance gain?, and it reduces the amount of code that needs to be maintained.^[45]

-RAMDAX Driver Merged For Linux 6.19 To Carve Out RAM As NVDIMM Devices^[44]

-Improved Block Layer Peer-To-Peer DMA^[41]

-Allow File-Systems To Increase The Writeback Chunk Size^[46]

Eric, god of cryptography optimization, Biggers brought us a new batch of patches. (BTW, same guy that brought the DM-VERITY patch..)

AES-GCM got a 74% performance boost on AMD Zen 3 CPUs^[23]

This optimization was achieved by implementing the instructions from AVX2 which are sufficient for AES-GCM as it can run on 256 bits registers. The already existing AVX512 implementation was also made more efficient when it comes to bigger amount of data.

Eric had already optimized AES-GCM for CPUs without AVX2 or AVX512 in 6.11 ^[24]

AMD'S x2AVIC (their implementation of a Advanced Programmable Interrupt Controller(APIC) for VMs, (not secure Avic....)) now supports up to 4096 instead of 512 VCPUs using the x2AVIC_EXT feature bit.^[7]

Overhaul the TDX code to address systemic races where KVM (acting on behalf of userspace) could trigger lock contention in the TDX-Module. ^[8]

Live Update Orchestrator (LUO) has been added to the kernel.

LUO builds on Kexec which is the tool that allows a kernel to pass control to another kernel, allowing updates without full reboot.

Kexec normally requires the devices you use to still go through a reset process and the data you have in memory would usually be lost in the transition.

LUO gives the administrator a way to preserve the state of the devices and memory regions that can than be reclaimed by the new kernel.

This will be used in the context of Virtual Machine hosts that need to keep the downtime as low as possible.^[50]

The Nouveau Driver now supports Larger Page size Compression.

So here we are talking about the DRM side driver.

It has been a requirement by Vulkan that the User Space be directly responsible for the management of the VRAM.

This concept is called User Virtual Memory Management (UVMM) and was implemented in the kernel as VM_BIND, a method that allows the User Space to directly map some memory to the VRAM.

+

Before this release, the Nouveau driver could only handle pages the size of the kernel page size, so most likely 4Kb. ^[37]

This is an issue as the GPU doesn't have the same sophisticated circuitry that allows a CPU to efficiently page walk.

The compression was added at the same time, as the Nvidia GPUs can only compress when the page size is 64KB or bigger.

This means better performance for all GPU demanding task.^[38]

Intel Nova Lake (Late 2026) Audio support enabled along with Xe3P integrated graphics in these CPUs getting enabled as well.^[10]

-Support Intel's Adaptive Sharpness Filter "CASF" With Lunar Lake^[34]

-There is also support for other audio hardware like the SpacemiT K1, Qualcomm QCM2290, Line 6 POD HD Pro X audio effects processor, and other hardware.^[10]

-Nova Driver Landing Boot42 Support For Next-Gen NVIDIA GPUs^[35]

-Initial GPU Support For Snapdragon X2 Elite In Linux 6.19^[36]

-Arm Ethos NPU Accelerator Driver^[39]

-Intel Color Management Xe VFIO Driver ^[40]

a busy lock at the transfer queuing layer was replaced with a lock-less list.

This patch yielded a 4x improvement in heavy transfer workloads.

The merge request states "_sending twice the number of packets per second, for half the cpu cycles._"

Good news.^[47]

The subsystem for Memory Management Concurrency ID (MM CID) and Restartable Sequences (RSEQ) has had a major rewrite.

Kernel legend Thomas Gleixner took the task and his work resulted in a major performance gain.

Lets start by understanding what MM CID and RSEQ are.

It is common for a program to require a Per-CPU data structure.

Meaning some chunk of data that should be accessible and loaded to only one CPU.

This allows Swift transaction and lower contention in critical code.

One way to create such Per-CPU data structure is to create one per core. But in the context of a CPU with a large core count, it can be a huge waste of memory. (think of needing it only for 5 cores on a 200 core machine)

The solution is the MM CID, it allow you to set a number of Concurrency IDs that will use said data structure.

Whenever a thread that requires a CID wakes up, it will take a CID from the pre-generated array.

Once that thread goes to sleep, the CID isn't instantaneously freed from the core, This allows the thread to quickly wake up if needed.

In the case where that core is used and that the CID array is empty, it would then be freed from the original core and sent to a new one.

MM CID also plays into NUMA, The hardware information that allows us to know how close a core is to another, and allows some optimizations.^[30]

+

MM CID is more of a kernel_space concept, To take advantage of it, the user will use Restartable Sequences (RSEQ).

RSEQ is used with great result with Databases and the rewrite showed around 14% performance gain, which is very good! ^[29]

printk() got a 20X speedup in some circumstances...

printk() , the command used to send text to the console, worked by granting a lock to the core that was currently using the console and waiting on said core to release the lock. This could result in large delays in the release of the lock in Realtime (RT) kernels. The solution was to change the internal code of printk() to offer a one line print solution that sets and releases the lock. This removed the contention and, in the example of the PocketBeagle 2 used for testing, went from a 145s boot time to 7s...^{[48] [49]}

-Turbostat in Linux 6.19 adds some new last level cache (LLC) statistics of: Last Level Cache Thousands of References Per Second "LLCkRPS" and Last Level Cache Hit % "LLC%hit". These LLC cache statistic reporting features were added by Intel.^[14]

Initial support (very basic) for the Tenstorrent Blackhole SoC.^[2]

The Tenstorrent Blackhole SoC is made up of four RISC-V CPU tiles of four SiFive X280 cores. (total 16 Cores).

Good for running local AI.

P100a (28GB ram) retails for $999 USD while the Blackhole P150a (32GB ram + 4x High speed ports) is currently marketed at $1399 USD.^[1]

Initial Black Sesame Technologies C1200 support. (Automotive SoC ARM64-based hardware.)^[4]

Chinese company had made some hardware for the last 9 years but without linux support until now^[3]

Black Sesame's C1236 is promoted as China's first single-SoC for "pilot navigation smart driving"

Support for the StarFive VisionFive 2 Lite Risc-V Board.

Should be the cheapest board with Risc-V cores on the market. Still, this isn't a Arm (Raspberry pi) killer, Performance/$ is still better with ARM.^[6]

-Support for the Anlogic dr1v90 (yes, Anlogic not Amlogic) FPGA platform using a single Nuclei UX900 RISC-V core.

-Renesas R-Car X5H (R8A78000) is now added as a new automotive SoC with 16 x Arm Cortex-A720 cores.

-The TI AM62L SoC is also added as a new GPU-less industrial SoC.

-The Qualcomm Snapdragon 430 (MSM8937) is finally upstream as an older mobile phone SoC based on the Arm Cortex A-53.

-The ASUS Zenbook A14 with Snapdragon X Plus X1P42100 SoC is now supported by the mainline kernel.

-The Lenovo ThinkBook 16 with the Snapdragon X Plus X1P42100 SoC is also now supported by mainline.

-A new driver for cache management on CXL devices with memory shared in a coherent cluster.^[5]

-Continued Intel Wildcat Lake ID additions across different drivers like the Intel PMC and VSEC drivers.^[9]

Linux 6.19-rc1

Linux 6.19-rc2

Linux 6.19-rc3

Linux 6.19-rc4

Linux 6.19-rc5

Linux 6.19-rc6

Linux 6.19-rc7

Linux 6.19-rc8

Linux 6.19

Major sources:

https://www.phoronix.com/review/linux-619-features-changes

https://kernelnewbies.org/Linux_6.19