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

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

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

Release Highlights

Linux Kernel v7.1 includes 47 commits to the CXL and DAX subsystems:

CategoryCommits
New Features & Hardware1
Bug Fixes5
Refactoring & Cleanup5
Testing1
Other35

The v7.1 CXL/DAX cycle is defined by three interlocking themes: laying the groundwork for Type 2 accelerator support, hardening the DAX/HMEM subsystem against a cluster of correctness bugs, and a focused refactoring of the region layer that splits a monolithic file into purpose-specific translation units. None of these is a headline splash feature on its own, but together they represent the kind of steady, unglamorous investment that makes the subsystem reliable enough to build production systems on.

Type 2 support — CXL devices that expose accelerator-attached memory rather than pure memory expanders — takes a significant step forward. Internal structures previously locked inside cxl_pci are now exported so that out-of-tree and in-tree Type 2 drivers can bind against them, and cxl_dev_state initialization now accounts for the Type 2 device class from the start. Alongside this, generic PCI utility code migrates from cxl_pci into core/cxl_pci, giving both the core and Type 2 drivers a shared, stable foundation without duplication.

On the DAX/HMEM side, this release resolves a longstanding ambiguity around Soft Reserved memory ownership — the question of whether a given ACPI-advertised memory range belongs to CXL region management or to the legacy dax_hmem driver. A new containment helper in cxl/region allows that decision to be deferred and resolved cleanly at driver bind time rather than at boot, eliminating a class of singleton confusion bugs and fixing a dependency ordering issue between dax/cxl and dax/hmem that could cause incorrect initialization ordering in multi-device configurations.

Key Changes

  • Type 2 accelerator device support: Internal CXL structs are now exported to allow external Type 2 drivers to participate in the CXL stack, and cxl_dev_state initialization correctly identifies Type 2 devices. This is a prerequisite for CXL-attached accelerators (GPUs, FPGAs, smart NICs) to interoperate with the kernel’s memory management and RAS infrastructure.

  • 32-switch decoder support: cxl/hdm now supports up to 32 switch-level decoders, up from the previous limit. This matters for large fabric topologies — multi-host CXL switches in disaggregated memory configurations — where the old cap became a real constraint.

  • Soft Reserved ownership resolution: A new helper checks whether a Soft Reserved EFI memory range is already covered by a CXL region, and dax_hmem defers claiming those ranges until CXL binding has had a chance to run. This eliminates a race where dax_hmem could steal memory that the CXL region driver was entitled to manage.

  • Region lock status sysfs interface: A new sysfs attribute exposes whether a CXL region is locked, giving userspace tools (and udev rules) a reliable, race-free way to query region state without parsing kernel log output.

  • Region code split into region_dax.c and region_pmem.c: The DAX and PMEM region driver logic is extracted from a single sprawling file into two focused translation units. This is maintenance work, but it reduces the cognitive overhead for contributors working on only one media type and makes future specialization easier.

  • PCI reset decoder flag clearing: When a cxl_memdev undergoes a PCI-level reset, endpoint decoder flags are now explicitly cleared. Without this, stale flag state could cause the driver to misinterpret post-reset device status, leading to incorrect region assembly or missed error events.

  • Use-after-free fix in region auto assembly: A reference-counting bug in the region auto-assembly failure path could cause a freed region object to be accessed during cleanup. The fix ensures teardown ordering is correct and is a straightforward but important memory safety correction.

  • fsdev_dax_zero_page_range() uninitialized kaddr fix: A missing initialization in the DAX filesystem zero-page path left kaddr undefined under certain conditions, producing unpredictable behavior when zeroing page ranges through a DAX-mapped filesystem. The fix initializes kaddr unconditionally before use.

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

Tags:

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

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

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

Release Highlights

Linux Kernel v6.17 includes 32 commits to the CXL and DAX subsystems:

CategoryCommits
New Features & Hardware1
Bug Fixes6
Refactoring & Cleanup3
Other22

The v6.17 cycle for CXL and DAX is a consolidation release rather than a feature-heavy one, with 32 commits that reflect the subsystem maturing around correctness, specification compliance, and architectural hygiene. The most visible theme is alignment with CXL specification revision 3.2: the Common Event Record has been updated to match the new spec, the Memory Sparing Event Record gains kernel tracing support for the first time, and additional validity checks land for corrected volatile memory error (CVME) counts in both DRAM and General Media Event Records. This work strengthens the kernel’s ability to correctly interpret and surface CXL RAS events to userspace tooling and monitoring infrastructure.

Read More
How I Created a Custom ChatGPT Trained on the CXL Specification Documents

How I Created a Custom ChatGPT Trained on the CXL Specification Documents

If you’re working with Compute Express Link (CXL) and wish you had an AI assistant trained on all the different versions of the specification—1.0, 1.1, 2.0, 3.0, 3.1… you’re in luck.

Whether you’re a CXL device vendor, a firmware engineer, a Linux Kernel developer, a memory subsystem architect, a hardware validation engineer, or even an application developer working on CXL tools and utilities, chances are you’ve had to reference the CXL spec at some point. And if you have, you already know: these documents are dense, extremely technical, and constantly evolving.

Read More
Understanding STREAM: Benchmarking Memory Bandwidth for DRAM and CXL

Understanding STREAM: Benchmarking Memory Bandwidth for DRAM and CXL

In today’s Artificial Intelligence (AI), Machine Learning (ML), and high-performance computing (HPC) landscape, memory bandwidth is a critical factor in determining overall system performance. As workloads grow increasingly data-intensive, traditional DRAM-only setups are often insufficient, prompting the rise of new memory expansion technologies like Compute Express Link (CXL). To evaluate memory bandwidth across DRAM and CXL devices, we use a modified industry-standard tool called STREAM.

In this blog, we’ll explore what STREAM is, how it works, why it’s commonly used for benchmarking memory bandwidth, and how a modified version of STREAM can be used to measure performance in heterogeneous memory environments, including DRAM and CXL.

Read More