引言：为什么数据中心需要一次内存架构革命

如果你管理过数据中心服务器，一定会对一个问题感到困惑：某些服务器内存使用率长期超过90%，系统频繁swap、OOM kill，而隔壁机架的服务器插满了DDR5内存条，使用率却不到30%。更让人抓狂的是，你无法把后者的空闲内存"借"给前者——它们物理隔离在不同主机的内存控制器后面。

CXL（Compute Express Link）就是为解决这个根本性问题而生的。它不是要替代PCIe，而是借用PCIe的物理层和软件生态，在协议层引入缓存一致性和内存语义，让内存从"绑定在主板插槽上的固定资源"变成"可以通过网络拓扑灵活扩展和共享的逻辑资源"。Intel、AMD、ARM、Google、Meta、微软等巨头几乎全员参与，CXL已经成为下一代数据中心互连的事实标准。

本文将从Linux内核底层实现的视角，深入拆解CXL的全套技术栈——从PCIe物理链路到FLIT数据链路协议，从HDM内存一致性模型到Linux NUMA分层调度，从cxl.Type3设备驱动到CXL 3.0 Fabric组网——给出一份从原理到工程落地的完整指南。

一、PCIe的局限与CXL的诞生逻辑

1.1 从"公路"到"计算快车"

理解CXL的关键前提是要清晰认识PCIe的设计目标和局限性。PCIe是为"主机与设备之间的I/O数据搬运"设计的——它的DMA引擎很擅长大块吞吐，但协议本身不管数据一致性。当你把数据从系统内存拷贝到GPU显存，整个过程涉及多次总线事务、驱动同步、地址映射切换，延迟高、带宽利用率低。

CXL的设计哲学可以概括为：物理层用PCIe，协议层重写语义。它继承了PCIe的SerDes、连接器、链路训练、电气特性，不需要重新设计机箱背板或金手指，但在链路建立之后，跑的不再是单纯的I/O数据TLP（Transaction Layer Packet），而是CXL.io、CXL.cache、CXL.mem三种承载不同语义的协议流。

1.2 为什么缓存一致性如此重要

在一个AI推理场景中，推理请求数据放在主机内存，模型权重放在GPU显存。传统流程下，每轮推理需要：

1. CPU准备输入batch → 写入主机内存
2. Driver提交DMA描述符 → 拷贝到GPU显存
3. GPU计算完成 → 结果拷回主机内存
4. CPU后处理 → 输出结果

这套流程中数据经历了至少两次PCIe DMA拷贝。而CXL.cache允许GPU直接缓存主机内存数据，硬件维护一致性，省掉了第2步和第3步的显式拷贝。端到端延迟可以从十几微秒降至两三微秒——这就是缓存一致性对计算密集型负载的价值。

二、CXL三大协议拆解：CXL.io / CXL.cache / CXL.mem

2.1 CXL.io：设备发现与控制面基础

CXL.io是所有CXL设备的强制协议，本质上沿用PCIe的TLP事务模型。它负责：

• 设备枚举：类似PCIe标准枚举，通过配置空间发现设备BAR、能力寄存器
• 中断处理：MSI/MSI-X中断投递机制
• DMA操作：传统I/O模式下的数据传输
• 错误上报：AER（Advanced Error Reporting）兼容
• BAR映射：分配和访问设备的MMIO寄存器区域

Linux内核中，CXL.io的处理路径几乎与原生PCIe驱动完全一致——pci_driver的probe/remove流程、resource管理、中断注册，全部复用。你可以在/sys/bus/pci/devices/下同时看到PCIe设备和CXL设备的sysfs节点。

2.2 CXL.cache：硬件缓存一致性协议

CXL.cache是让加速器（GPU、FPGA、DPU）安全地缓存主机内存的协议。它实现了一个基于snooping的MESI类一致性模型：

关键概念：

• Host-managed Device Cache（HDC）：设备端的缓存，由CXL.cache协议管理
• Snoop Filter：CPU一致性域内的跟踪结构，记录哪些设备缓存了哪些cache line
• Device to Host Request（D2H）：设备发起的缓存操作请求（Read、Read0、Write等）
• Host to Device Request（H2D）：CPU发起的设备侧缓存维护（Snoop、Dataless Snoop等）

D2H请求类型：

H2D请求类型（CPU对设备缓存的操作）：

Linux内核中的实现：CXL.cache的一致性域管理由cxl_region子系统负责。当一个CXL Type 2或Type 1设备被添加到一致性域时，cxl_pci驱动通过ACPI CEDT（CXL Early Discovery Table）获取设备的HDM（Host-managed Device Memory）范围，注册到cxl_root_decoder。一致性域内的所有设备共享同一个snoop filter，由Intel PAMD（Platform AMDirectory）或在软件层面维护。

2.3 CXL.mem：CPU直接访问设备内存

CXL.mem是让主机CPU用普通load/store指令访问外部设备内存的协议。它是Type 3设备的核心技术，也是CXL内存池化得以实现的基础。

CXL.mem的关键事务类型：

• MemRd（Memory Read）：CPU读取CXL设备内存
• MemWr（Memory Write）：CPU写入CXL设备内存
• MemInv（Memory Invalidate）：设备侧Cache line失效通知
• MemSpecRd（Speculative Read）：推测性读取，用于硬件预取

CXL.mem事务在链路层封装为FLIT（Flow Control Information Unit）——这是CXL数据链路层的核心传输单元。FLIT内部包含多个slot，每个slot编码不同的事务层信息：

• Template：标识FLIT中各slot的使用方式
• slot 0-3：承载具体的请求或响应数据
• CRC：每个FLIT末尾包含CRC校验
• Protocol ID：区分CXL.io、CXL.cache、CXL.mem三种协议流

三、CFLIT协议与数据链路层详解

3.1 FLIT结构：CXL链路上的"标准集装箱"

FLIT是CXL 2.0及以后版本在数据链路上传输的标准帧单元。对于PCIe 5.0（CXL 2.0使用），FLIT大小为256字节（与PCIe 5.0的TLP+Framing一致）。对于CXL 3.0（基于PCIe 6.0），仍使用256B FLIT但编码方式从128b/130b升级为PAM-4。

一个标准CXL 2.0 FLIT的结构：

+--------+--------+--------+--------+-----+------+
| Slot 0 | Slot 1 | Slot 2 | Slot 3 | CRC | FEC |
+--------+--------+--------+--------+-----+------+
  52B      52B      52B      52B     8B    (opt)
   ↑                                    ↑
  Header/Link                           错误检测
  Control                               与纠正

每个slot 52字节中进一步分为：

• Template Field（2B）：指示该FLIT中各slot的用途（如"3个请求+1个响应"等组合）
• Protocol ID（1B）：区分CXL.io/cache/mem三种协议流
• Remaining（49B）：承载具体的事务数据（请求头、数据负载等）

Template字段至关重要——它让FLIT可以在一个帧中混合传输不同类型的事务：

Template = 0b00: 4个Generic（任意类型）
Template = 0b01: 1个H2D Response + 1个H2D Data + 2个D2H Request
Template = 0b10: 4个D2H Response（含数据）
Template = 0b11: 混合模式（H2D + D2H交错）

3.2 CXL缓存一致性协议的具体操作

CXL.cache的一致性操作可以归纳为以下几种场景（以Type 2设备读取主机内存为例）：

场景一：设备首次读取某个内存地址

1. 设备发起 RdAny 请求到Host
2. Host的Snoop Filter检查是否有其他设备或CPU核心缓存了该line
3. 如果CPU缓存有最新数据（Modified状态）→ Host发起Snoop Invalid/Shared
4. CPU将缓存line数据回写或转发给Host
5. Host将数据返回给设备（带appropriate cache state）

场景二：设备要修改已经缓存的数据

1. 设备发起 RdOwn 请求（获取Exclusive/Modified权限）
2. Host Snoop Filter找到所有其他缓存副本
3. Host向所有共享者发送 Snoop Invalid（强制失效）
4. Host将数据返回给设备，设备进入Modified状态
5. 设备可以自由修改，无需通知Host

场景三：CPU要修改设备已缓存的数据

1. CPU尝试写入某地址，但Snoop Filter显示设备缓存了该line
2. CPU向Host发送请求，Host向设备发送 Snoop Invalid
3. 设备失效自己的cache line，返回确认（如果需要则回写脏数据）
4. CPU获取独占权，执行修改

四、HDM内存一致性模型

4.1 HDM-H 与 HDM-D：两种不同的编址模式

CXL引入了两个关键内存概念：

HDM-H（Type 3设备）：整个内存系统在CPU和设备视角下一致，设备内存由主机MMU直接管理。主机格式化、分区、暴露这些内存的方式与传统NUMA内存类似。

HDM-D（Type 2设备）：设备有自己的本地HDM-D内存（如GPU显存映射到CXL.mem），设备内部的内存管理单元（如GPU MMU）独立管理本地内存。同时设备可以通过CXL.cache访问主机的HDM-H空间。这种模式下，一致性域分为两层：主机一致性域（HDM-H）和设备一致性域（HDM-D），通过CXL.cache的snoop filter桥接。

4.2 CXL 3.0的全局一致性（Global Fabric Attached Memory）

CXL 3.0的重大突破是引入了双向一致性（Bi-Directional Coherence）和P2P缓存一致性（Peer-to-Peer Coherence）。

在CXL 2.0中，一致性是从Host到设备的单向链路——Host可以管理设备缓存，设备也可以缓存Host内存，但设备之间不能直接共享缓存。CXL 3.0通过Fabric Manager和新的路由机制，允许：

• Type 2设备之间直接缓存一致性（P2P coherence）
• 跨多主机共享的内存区域（Global Shared Memory）
• 多级CXL Switch形成的一致性域扩展

一致性域的实现方式从单纯的snooping演进为snooping + directory的混合模型：小范围（单主机+直连设备）用snoop filter；大范围（多级Switch+多主机）用directory-based方案，directory存放在Host内存或CXL交换机中。

五、Linux内核CXL子系统架构

5.1 子系统演进历程

5.2 关键数据结构

Linux内核中CXL子系统的核心组件关系：

struct cxl_root_decoder    // 根解码器：映射CXL设备的HDM空间到主机物理地址
  ├── struct cxl_switch_decoder  // 交换机解码器：Switch中的路由上下文
  │     └── struct cxl_port          // CXL端口（Downstream Port / Upstream Port）
  │           └── struct cxl_memdev   // 内存设备（Type 3的核心抽象）
  │                 ├── struct cxlr_region   // 内存区域（可online/offline）
  │                 └── struct cxl_endpoint_decoder // 端点解码器
  ├── struct cxl_region             // MLD（Multiple Logical Device）区域管理
  └── struct cxl_memdev             // 包含DCD（Dynamic Capacity Device）支持

关键路径的功能映射：

• cxl_pci：PCIe/CXL设备的总线驱动，负责枚举、BAR映射、中断分配
• cxl_mem：内存设备驱动，注册cxl_memdev，暴露/sys/bus/cxl/devices/memX
• cxl_acpi：ACPI表解析（CEDT、HMAT等），获取CXL设备布局和能力信息
• cxl_region：区域管理，负责将设备内存合并为可用的内存区域
• cxl_pmem：持久内存模式（Type 3可选功能），通过ndctl/DAX暴露

ACPI表在CXL初始化中的关键作用：

六、Linux内存管理子系统与CXL的集成

6.1 NUMA拓扑自动识别

CXL Type 3内存设备上线后，Linux内核将它自动注册为一个独立的NUMA节点。与本地DDR的区别在于通过ACPI HMAT表报告更高的访问延迟。

NUMA节点的拓扑发现流程：

1. ACPI HMAT/SLIT解析 → 填充 NUMA node_to_node_distance[]
2. cql_port注册 → 绑定到对应的NUMA node
3. cxl_region online → 调用add_pages()将物理内存加入buddy allocator
4. node register → /sys/devices/system/node/nodeN 节点创建

典型输出（双路服务器+2个CXL内存模块）：

$ numactl --hardware
available: 3 nodes (0,1,2)
node 0 cpus: 0-71,143-214
node 0 size: 257702 MB
node 1 cpus: 72-143,215-286
node 1 size: 257834 MB
node 2 cpus:
node 2 size: 524288 MB  ← CXL Type 3模块

node distances:
node   0   1   2
  0:  10  20  31
  1:  20  10  31
  2:  31  31  10   ← CXL内存节点距离本地31（约为本地DDR的3倍）

6.2 AutoNUMA Balancing与CXL

Linux 6.x引入了AutoNUMA Balancing（/proc/sys/kernel/numa_balancing），它能自动检测页面访问模式，将频繁访问的页面迁移到本地NUMA节点。这对CXL内存特别重要——如果进程的大量页面被分配到CXL NUMA节点上，内核的NUMA balancing机制可以：

• 检测到远端访问开销过高
• 将hot pages迁移到本地DDR节点
• 将cold pages降级到CXL内存节点
• 持续自适应调整页面分布

具体实现路径：

scan_numa_nf_pages()          # 周期性扫描NUMA hinting faults
  └→ migrate_misplaced_pages()   # 需要迁移的页面
      └→ cxl_mem_page_migrate()  # CXL内存专用迁移路径

CXL内存的迁移与本地DDR不同——需要考虑目标节点的内存设备特性。内核通过设置迁移目标回调，让cxl_mem模块在迁移前确认设备是否处于正常状态、是否有足够的空闲空间。

6.3 Memory Tiering分层管理

Linux 6.6+引入了正式的Memory Tiering框架（CONFIG_NUMA_MEMBLKS），允许内核将不同延迟特性的内存分为不同tier：

auto-tiering的配置方式：

# 开启demotion（降级到低速层级）
echo 1 > /sys/kernel/mm/numa/demotion_enabled

# 查看当前tier和迁移统计
cat /sys/devices/system/node/node2/memtier
# target=2, demotion_fallback=1, promotion_target=0

七、CXL Type 3设备驱动深度分析

7.1 设备初始化完整流程

一个CXL Type 3设备的完整初始化链路（以Linux 6.8为例）：

BIOS/UEFI阶段:
  ACPI表生成（CEDT + HMAT + SLIT）
  CXL链路训练（PCIe 5.0/6.0协商后降级到CXL模式）

内核启动:
  cxl_acpi_init()
    └→ cxl_cedt_parse()       ← 解析CEDT获取Host Bridge范围
    └→ cxl_bus_init()         ← 注册bus_type cxl_bus_type

PCI枚举:
  pci_scan_slot() → 发现03:00.0 (Class 0502: CXL Memory Device)
  cxl_pci_probe()
    ├→ cxl_pci_enable_device()  ← 使能PCIe/CXL功能
    ├→ cxl_hdm_decode_init()    ← 初始化HDM解码器
    │    └→ 读取寄存器:
    │        CAP: HDM Count, DRAM Capable, Cache Capable
    │        配置: HDM Decoder Base/Length
    └→ cxl_memdev_register()    ← 注册cxl_memdev设备

Region创建:
  cxl_cmd_create_region()
    └→ cxl_region_instantiate() ← 实例化region
    └→ memory_group_register()  ← 加入memory group

内存上线:
  echo online > /sys/devices/system/memory/memoryN/state
    └→ memory_block_online()
    └→ add_pages(node, start_pfn, nr_pages)
    └→ online_pages()

NUMA节点创建:
  node_online(node_id) → 注册NUMA节点到 sysfs

7.2 DCD（Dynamic Capacity Device）支持

DCD（Dynamic Capacity Device）是CXL 2.0引入的一项重要特性——Type 3设备的容量可以在运行时动态改变，不需要重启或卸载驱动。DCD的实现基于一系列新命令：

• Get Dynamic Capacity Config：查询设备容量能力和扩展窗口
• Get Dynamic Capacity Region List：列出可以动态扩展的区域
• Get Dynamic Capacity Extent List：列出可扩展的extent列表
• Add Dynamic Capacity：增量通知主机设备端新增了可用容量

Linux内核中的DCD实现（6.8+）：

// 触发DCD容量扩展
echo "add " > /sys/bus/cxl/devices/mem0/dax_region//resource
  └→ cxl_dc_extent_process()
    └→ cxl_region_perf_dc_extents()
      └→ add_pfn_range()   ← 动态扩展NUMA节点的物理地址范围

DCD在内存池化场景下特别有用——CXL交换机可以根据主机的实时负载，动态调整每个主机可用的内存容量，而主机侧通过DCD机制感知容量变化并自动调整。

八、CXL 2.0 Switch与多逻辑设备（MLD）

8.1 CXL Switch的内部架构

CXL Switch是CXL 2.0的核心组件，它不是简单的数据转发器，而是：

• 地址路由：根据目标地址将请求报文转发到指定端口
• ID路由：MLD场景下按Logical Device ID路由
• 流量控制：每个端口独立的流控信用机制
• QoS：基于VC（Virtual Channel）的优先级控制
• 错误隔离：单个端口错误不影响其他端口转发

Switch在Linux内核中的抽象层：

struct cxl_switch_decoder
  ├── struct cxl_port *port;              // Switch端口引用
  ├── struct list_head target_list;       // 目标端口列表
  ├── u64 *target_ports;                  // 目标端口ID数组
  ├── u8 *qos;                            // QoS端口优先级
  └── struct cxlm_region *region;         // 可分配区域描述

struct cxl_port
  ├── struct cxl_switch_decoder *decoder; // Switch解码器（如果有）
  ├── struct cxl_root_decoder *root;      // 根解码器（Root Port）
  ├── struct cxl_memdev *memdev;          // 内存设备
  └── enum cxl_port_type type;            // RP / USP / DSP

8.2 Multiple Logical Device（MLD）机制

MLD（多逻辑设备）允许一个物理CXL设备拆分成多个独立的逻辑设备，每个逻辑设备被独立分配给不同的主机。这样一台物理CXL模块就能同时服务多个业务，彼此隔离。

配置MLD的典型场景：

物理设备: 512GB CXL Type 3内存卡（单端口连接Switch）
├── Logical Device 0 → 分配 128GB 给 Host A (node2)
├── Logical Device 1 → 分配 256GB 给 Host B (node2)
└── Logical Device 2 → 分配 128GB 给 Host C (node3)

Linux中通过cxl-cli工具配置MLD：

# 查看Switch拓扑
cxl list -S -b

# 为指定主机分配逻辑设备
cxl create-mld --port 0 --lvd-count 3 \
  --lvd-sizes 128G,256G,128G \
  --targets host-a,host-b,host-c

# 各主机端在线自己的LVD
cxl create-region --memdev mem0 --mode=ram
echo online > /sys/devices/system/memory/memory0/state

MLD的内核实现细节：

• 每个LVD有一个独立的Port Binding和Register Space
• 不同LVD的HDM地址空间互不重叠
• CXL Switch的BBN（Base Bus Number）和LUT（Lookup Table）确保请求只发到正确的LVD
• Host端的ACPI CEDT中包含每个LVD的内存范围声明

九、CXL 3.0 Fabric与CXL Switch升级

9.1 Fabric topology：从总线到网络

CXL 3.0的最大变化是将CXL从"单主机内存总线"扩展为可跨多主机、多级交换的Fabric。核心特性：

• 多级Switch（Multi-Level Switching）：支持CXL Switch下游连CXL Switch
• P2P缓存一致性（P2P Coherence）：Type 2设备之间可建立一致性域
• 全局Fabric Attached Memory（G-FAM）：内存可跨主机边界访问
• 协议复用：CXL.io/cache/mem在同一个Fabric上复用

CXL 3.0的物理层切换到PCIe 6.0（64 GT/s），带宽翻倍。FLIT结构也发生了变化——引入Flexible FLIT支持，允许不同协议流动态分配slot资源。

9.2 CXL 3.0的一致性域扩展

一致性域（Coherence Domain）是CXL中缓存一致性保证的范围。

Linux内核中的Coherence Domain实现（6.10+预览）：

struct cxl_coherence_domain
  ├── struct cxl_root *root;                  // 根一致性上下文
  ├── struct list_head device_list;           // 共享一致性的设备列表
  ├── struct radix_tree_root snoop_filter;    // snoop filter条目
  ├── rwlock_t lock;                          // 一致性域保护锁
  └── struct cxl_directory *directory;        // directory条目(G-FAM)

十、CXL Cache Coherence的深度机制

10.1 BIOS与OS的协同配置

CXL缓存一致性涉及BIOS与内核的协同：

1. BIOS阶段：
   • 通过ACPI表（CEDT）声明哪些Root Port启用CXL
   • 配置HDM Decoder寄存器（基址、长度、granularity）
   • 设置Snoop Filter/CAM range
   • 决定是否启用CXL.cache（有些场景为了确定性延迟会关闭）
2. 内核初始化：
   • cxl_acpi解析CEDT → 创建cxl_root
   • cxl_hdm_decode_init()读取设备HDM Capabilities
   • cxl_register_decoder()解码能力注册
   • cql_ide_configure() 配置Integrity & Data Encryption（安全链路）

# BIOS菜单中的CXL配置选项（典型UPI平台）
Processor Configuration →
  CXL Support [Enabled]
  CXL Security [AES-256-GCM]
  CXL IDE Enable [Type1,Type2,Type3]

Memory Configuration →
  CXL Memory Interleaving [Auto]
  CXL Snoop Filter CAM [/4]
  CXL Reserved QOS [75%]

10.2 Snoop Filter与Directory的选择

一致性域的实现有两种方式，场景决定选择：

现代实现通常是混合方案——snoop filter + IMC directory：小范围用snoop（延迟低），directory作为"cache"，snoop未命中时回退到directory查询。

// 内核中的snoop filter检查路径
static enum cxl_cache_check_result
cxl_cache_check_snoop(struct cxl_snoop_filter *sf,                       phys_addr_t addr, int cpu_core)
{
    uint64_t tag = addr >> CACHE_LINE_SHIFT;
    int bucket = tag & SF_BUCKETS_MASK;
    
    if (radix_tree_lookup(&sf->entries, tag)) {
        return SNOOP_HIT;
    }
    return SNOOP_MISS;  // 回退到directory检查
}

#!/bin/bash
# QEMU CXL Type 3 模拟 (4GB CXL内存设备)

DEVSHM=/dev/shm/cxl_memory
dd if=/dev/zero of=$DEVSHM bs=1M count=4096 2>/dev/null

qemu-system-x86_64 \
  -machine q35,cxl=on \
  -cpu host \
  -smp 8 \
  -m 8G \
  -bios /usr/share/ovmf/OVMF.fd \
  -nographic \
  -object memory-backend-file,id=cxl-mem0,size=4G,mem-path=$DEVSHM \
  -device pxb-cxl,bus=pcie.0,id=cxl.1,bus_nr=128 \
  -device cxl-rp,id=rp0,bus=cxl.1,addr=0 \
  -device cxl-type3,bus=rp0,memdev=cxl-mem0,id=cxl-dev0,fw-max-sbep=2

# 1. sysfs检查
$ ls /sys/bus/cxl/devices/
mem0  root0  port1  decoder0.0  decoder1.0  region0

# 2. dmesg查看cxl初始化
$ dmesg | grep -i cxl
[3.220] cxl_acpi 00:00: CXL ACPI: CEDT found, 1 CHB
[3.550] cxl_port 01:00: CXL RP: port registered, HDM decoder count: 1
[3.680] cxl_mem 02:00: CXL Type 3: 4096MB, DPA range: 0x100000000-0x200000000

# 3. lspci确认
$ lspci -vvv -s 01:00.0
01:00.0 PCI bridge: Redhat CXL Root Port
    Capabilities: CXL v2.0
        HDM Decoder: 1, For Type 3 Device

# 4. 创建region并online
$ cxl create-region --memdev mem0 --mode=ram -w 1
echo online > /sys/devices/system/memory/memory8/state

# 5. NUMA确认
$ numactl --hardware | tail -5
available: 2 nodes (0, 1)
node 1 cpus:
node 1 size: 4032 MB  ← CXL内存上线成功

# 模拟CXL Switch + 多MLD配置（需要QEMU 8.2+）
qemu-system-x86_64 \
  -machine q35,cxl=on \
  -m 32G,slots=4,maxmem=288G \
  -object memory-backend-ram,id=host-mem0,size=16G \
  -object memory-backend-file,id=cxl-pool0,share=on,size=256G,mem-path=/dev/shm/cxl_pool \
  -device pxb-cxl,bus=pcie.0,id=cxl-pb,bus_nr=128 \
  -device cxl-rp,id=rp0,bus=cxl-pb \
  -device cxl-upstream-port,id=usp0,bus=rp0 \
  -device cxl-switch-up,id=us0,bus=cusp \
  -device cxl-switch-down,id=ds1,port=0,bus=us0,vppb-endpoint=rp1 \
  -device cxl-type3,bus=rp1,memdev=cxl-pool0,id=cxl-mem1

# 策略1：显式绑定热数据到本地，大数据到CXL
# 应用代码中使用set_mempolicy()配合mbind()
#include 
unsigned long nodemask = (1 << local_node);
set_mempolicy(MPOL_BIND, nodemask, MAXNUMAFLAGS);

# 策略2：CXL内存作为"大池"，本地DDR作为"热区"
# 在Linux 6.6+中启用auto-tiering
echo 1 > /sys/kernel/mm/numa/demotion_enabled
echo 1 > /proc/sys/kernel/numa_balancing_settle_count

# 策略3：利用GFlags对CXL内存进行带宽分配
# Intel平台的CXL QoS Tuning
pqos -e "llc:0=0x000f"  # 限制CXL内存代理的LLC使用

# /etc/default/grub 内核参数
GRUB_CMDLINE_LINUX="numa_balancing=enable \
  numa_favor_delay=200 \
  cxl_acpi.snoop_filter=1 \
  cxl_region.round_robin=1"

# 关键参数说明：
# numa_balancing=enable       → 开启NUMA自动迁移
# numa_favor_delay=200        → 200ms延迟后开始降级冷页
# cxl_acpi.snoop_filter=1     → 使用硬件snoop filter加速
# cxl_region.round_robin=1    → Region分配时Round-Robin交织

# 在BIOS中开启IDE支持（针对CXL Root Port）
# 内核编译时需开启 CONFIG_CXL_IDE

# 运行时验证
$ cat /sys/bus/cxl/devices/pex0/ide_enabled
1

# 查看IDE密钥槽（Key Slot）状态
$ cat /sys/bus/cxl/devices/pex0/ide_key_slot
slot0: AES-256, epoch=0x1000
slot1: AES-256, epoch=0x2000

# CXL Region级别的安全策略
$ cat /sys/bus/cxl/devices/region0/security
IDE mode: Full (TLS-like, all traffic encrypted)
Port association: root_port0 → device0