Linux Kernel v6.14 is Released: This is What's New for Compute Express Link (CXL)

Linux Kernel v6.14 is Released: This is What's New for Compute Express Link (CXL)

The Linux Kernel v6.14 release brings several improvements and additions related to Compute Express Link (CXL) technology.

Release Highlights

Linux Kernel v6.14 includes 13 commits to the CXL and DAX subsystems:

CategoryCommits
Bug Fixes1
Refactoring & Cleanup2
Other10

The dominant story in v6.14’s CXL changes is alignment with CXL specification revision 3.1 in the event subsystem. Five event record types — Common, General Media, DRAM, Memory Module, and Component Identifier — were updated to match the latest spec. These records are how CXL devices surface hardware faults, media errors, and performance anomalies to the host, so keeping them in sync with the specification is critical for accurate error classification and interoperability with newer hardware that implements the 3.1 format changes.

On the PCI side, cxl_dvsec_rr_decode() gains support for CXL Type 1 and Type 2 devices. Previously this DVSEC range register decode path only handled Type 3 (memory-expander) devices — the class that has driven most CXL software development to date. Extending it to Type 1 (cache-coherent accelerator, no device memory) and Type 2 (accelerator with device memory) broadens the driver’s device coverage and lays groundwork for a wider range of CXL-attached accelerators and smart NICs.

The cleanup work in v6.14 shows a continued push to use generic driver core primitives rather than CXL-specific wrappers. is_cxl_nvdimm_bridge() is removed from cxl/pmem in favor of the generic device_match_type() API, and device_find_child() in the driver core is constified to improve type safety across subsystems that include CXL. A prototype correction to device_for_each_child_reverse_from() rounds out the driver core fixes.

Key Changes

  • CXL 3.1 Event Record Updates: The Common, General Media, DRAM, and Memory Module event records are all updated to match CXL specification revision 3.1 field layouts. Devices implementing the newer spec will now have their reported events correctly parsed rather than silently misinterpreted.
  • Component Identifier Formatting (CXL 3.1): A new Component Identifier field introduced in CXL spec 3.1 is now formatted and exposed in event output, giving operators a structured way to pinpoint which component inside a device reported an event.
  • Type 1/2 Device Support in DVSEC Decode: cxl_dvsec_rr_decode() now handles CXL Type 1 (cache-coherent, no device memory) and Type 2 (with device memory) devices in addition to Type 3. This is a prerequisite for CXL-attached accelerators to participate in the driver’s range-register enumeration path.
  • NVDIMM Bridge API Modernization: is_cxl_nvdimm_bridge() and the internal match_nvdimm_bridge() helper are removed from cxl/pmem, replaced by the generic device_match_type() driver core API. This reduces CXL-specific boilerplate and keeps device-matching logic in one canonical place.
  • Register Block Counting Refactor: cxl/core/regs gains extracted helper functions for counting register blocks of a given type. The logic existed inline before; factoring it out makes the register enumeration code easier to test and reuse as new register block types appear in future spec revisions.
  • Driver Core Const-Safety: device_find_child() is constified in the driver core and its callers — including CXL paths — are updated. This closes a category of potential const-violation bugs in code that searches the device tree without intending to modify anything.
  • device_for_each_child_reverse_from() Prototype Fix: A mismatch between the function’s declaration and its actual signature is corrected. Left unfixed, this kind of prototype error can silently produce undefined behavior on architectures where the calling convention depends on argument types.

Here is the detailed list of all commits merged into the 6.14 Kernel for CXL and DAX. This list was generated by the Linux Kernel CXL Feature Tracker .

How to build an upstream Fedora Kernel from source

How to build an upstream Fedora Kernel from source

I typically keep my Fedora system current, updating it once every week or two. More recently, I wanted to test the Idle Page Tracking feature, but this wasn’t enabled in the default kernel provided by Fedora.

# grep CONFIG_IDLE_PAGE_TRACKING /boot/config-$(uname -r)
# CONFIG_IDLE_PAGE_TRACKING is not set

To enable the feature, we need to build a custom kernel with the feature(s) we need. Thankfully, the process isn’t too difficult.

For this walk through, I’ll be building a customised version of the Fedora 32 kernel version I already have installed (5.8.7-200.fc32.x86_64), using some of the instructions from https://fedoraproject.org/wiki/Building_a_custom_kernel .

Read More
Using Linux Kernel Memory Tiering

Using Linux Kernel Memory Tiering

In this post, I’ll discuss what memory tiering is, why we need it, and how to use the memory tiering feature available in the mainline v5.15 Kernel.

What is Memory Tiering?

With the advent of various new memory types, some systems will have multiple types of memory, e.g. High Bandwidth Memory (HBM), DRAM, Persistent Memory (PMem), CXL and others. The Memory Storage hierarchy should be familiar to you.

Memory Storage Hierarchy

Read More
Unlock Your CXL Memory: How to Switch from NUMA (System-RAM) to Direct Access (DAX) Mode

Unlock Your CXL Memory: How to Switch from NUMA (System-RAM) to Direct Access (DAX) Mode

As a Linux System Administrator working with Compute Express Link (CXL) memory devices, you should be aware that as of Linux Kernel 6.3, Type 3 CXL.mem devices are now automatically brought online as memory-only NUMA nodes. While this can be beneficial for most situations, it might not be ideal if your application is designed to directly manage the CXL memory as a DAX (Direct Access) device using mmap().

This blog post will explain this behavior and provide a step-by-step guide on how to convert a CXL memory device from a memory-only NUMA node back to DAX mode, allowing applications to mmap the underlying /dev/daxX.Y device. We’ll also cover troubleshooting steps if the memory is actively in use by the kernel or other processes.

Read More