Ch 6: CXL.io — PCIe와의 차이·DOE·DVSEC

#한 줄 요약

“CXL.io는 PCIe와 99% 호환입니다. 같은 enumeration, 같은 MMIO, 같은 DMA, 같은 AER.” — 다른 점은 디바이스가 CXL 호환임을 알리는 DVSEC과 SPDM·CMA·IDE_KM 같은 보조 프로토콜의 mailbox 채널 DOE입니다. CXL 1.1부터 정의됐고 모든 CXL 디바이스에 필수입니다.

Ch 5에서 CXL 4.0의 새 기능을 봤습니다. 이 장부터 프로토콜 별 본격 분해입니다. CXL.io는 가장 기본·필수인 프로토콜로, 전체 CXL 디바이스의 출발점입니다.

#CXL.io가 하는 일

CXL.io는 PCIe 시맨틱을 그대로 가져와 디바이스 발견·설정·DMA를 담당합니다.

PCIe 위에 100% 호환되므로 기존 host의 PCIe enumeration 코드가 그대로 동작합니다.

#CXL.io = PCIe + DVSEC + DOE

PCIe와 다른 부분 둘만 기억하면 됩니다.

이 둘만 CXL 고유 확장이고, 나머지는 모두 PCIe입니다.

#DVSEC — CXL 호환 표지

*DVSEC (Designated Vendor-Specific Extended Capability)*은 PCIe Spec 자체가 정의한 capability이지만, CXL Consortium이 자신의 vendor ID(0x1e98)를 사용해 CXL 호환 디바이스 식별 표지로 활용합니다.

운영 흐름:

1. Host의 PCIe enumeration이 config space scan
2. Extended Capability list에서 DVSEC 발견
3. Vendor ID = 0x1E98인 DVSEC을 보면 CXL 호환 디바이스로 인식
4. CXL subsystem 활성화, 추가 capability negotiation

Linux의 lspci -vvv로 확인:

1
$ lspci -vvv -s 5e:00.0 | grep -A 5 "Designated Vendor"
2
Capabilities: [60] Designated Vendor-Specific: Vendor=1e98 ID=0000
3
    Compute Express Link
4
    DVSEC Rev: 1, Len: 56
5
    ...

Vendor=1e98이 보이면 CXL 디바이스입니다.

#DOE — Boutique Protocol Mailbox

*DOE (Data Object Exchange)*는 PCIe 5.0부터 도입된 mailbox로, config space write/read를 통해 임의의 out-of-band protocol을 호스트와 디바이스 사이에 흘리는 채널입니다.

CXL이 DOE를 활용하는 보조 protocol:

하나의 mailbox에 여러 protocol이 시분할로 흐릅니다. Protocol ID로 분기.

DOE capability 확인:

1
$ lspci -vvv -s 5e:00.0 | grep -A 8 "Data Object Exchange"
2
Capabilities: [70] Data Object Exchange
3
    DOE Mailbox: 1 instance
4
    Supported Protocols:
5
        Vendor=DMTF, ID=0x01 (CMA SPDM)
6
        Vendor=DMTF, ID=0x02 (Secured CMA SPDM)
7
        Vendor=CXL, ID=0x03 (Compliance Mode)

DOE 없이도 기본 CXL.io 동작은 가능하지만, Security·Compliance 검증에는 필수입니다.

#UIO — Unordered I/O

CXL.io의 추가 특성 중 *UIO (Unordered I/O)*는 PCIe의 strict ordering보다 완화된 ordering을 명시적으로 허용하는 메커니즘입니다.

UIO의 가치:

• P2P 흐름 — accelerator 간 direct 전송이 strict ordering 부담 없이 가능
• Throughput — switch가 큐 분산·재정렬해 대역폭 활용 향상

UIO는 application이 명시적으로 요청해야 활성. 순서 보장이 필요한 control path는 기본 PCIe ordering 사용.

#Direct CXL.mem Access — P2P 메모리 접근

CXL 3.1부터 accelerator 간 direct P2P CXL.mem access가 가능해졌습니다. 이전에는 항상 host를 경유해야 했습니다.

P2P 흐름:

1. Accel A가 Accel B의 HDM memory address를 안다
2. UIO 활성화 후 직접 load/store
3. Host는 경유 안 함 — switch가 routing
4. Coherency는 BISnp로 유지 (HDM-DB의 경우)

GPU·NPU 간 distributed inference에서 모델 weight·KV cache의 P2P share가 가능해집니다.

#Linux 측 — CXL.io 인식 경로

Linux의 CXL subsystem 활성화가 CXL.io 인식에서 시작합니다.

1
# 1. PCIe enumeration 결과
2
$ lspci -nn | grep -i cxl
3
5e:00.0 Memory controller [0508]: ... [1234:5678]
4

5
# 2. CXL DVSEC 확인
6
$ lspci -vvv -s 5e:00.0 | grep -E "Designated|Compute Express"
7

8
# 3. CXL subsystem 등록 확인 (DVSEC 있어야 등록)
9
$ ls /sys/bus/cxl/devices/
10
mem0/ ...
11

12
# 4. DOE capability 활성 시
13
$ ls /sys/bus/cxl/devices/mem0/security/
14
state  user_keystore  ...

DVSEC이 없으면 cxl_acpi가 등록 안 함 → CXL 모드 동작 안 함. BIOS·firmware가 DVSEC을 정확히 보고해야 운영 가능.

#자주 하는 실수

#”CXL.io = PCIe 그대로면 그냥 PCIe 쓰면 된다”

DVSEC·DOE가 CXL 운영의 entry point입니다. DVSEC 없으면 host가 CXL.cache·CXL.mem 인터페이스 활성화 못 함. PCIe만으로는 CXL 디바이스의 핵심 기능 사용 불가.

#”DOE에 어떤 protocol이든 막 넣어도 된다”

Protocol ID가 등록된 것만 통신합니다. CXL Consortium·DMTF가 protocol ID를 관리. 임의 ID는 디바이스가 응답 안 함. SPDM·CMA·IDE_KM·Compliance가 현재 표준 set.

#”UIO 항상 켜는 게 좋다”

Ordering 보장이 필요한 path에 UIO를 켜면 데이터 무결성 위험. application 의도와 ordering 요구를 분석한 후 선택적 적용.

#”P2P CXL.mem은 host overhead 0”

Routing overhead는 있습니다. Switch가 P2P 라우팅 결정에 수십 ns. 또한 *coherency 유지 (BISnp 트래픽)*가 추가됨. host 라운드트립보다 빠른 것이지 cost가 0은 아닙니다.

#”DOE mailbox는 빠르다”

Config space write/read 기반이라 slow path입니다. 수 µs~수 ms. bulk data는 DOE로 보내면 안 되고, DMA·MMIO 사용. DOE는 control plane (인증·키 교환) 전용.

#정리

• CXL.io는 PCIe와 99% 호환 — 같은 enumeration·config·MMIO·DMA·AER.
• 다른 점은 DVSEC (CXL 호환 표지)와 DOE (보조 protocol mailbox) 둘.
• DVSEC vendor ID 0x1E98이 CXL Consortium의 표지. 모든 CXL 디바이스 필수.
• DOE는 SPDM·CMA·IDE_KM·Compliance protocol을 mailbox로 흘림. Security·Compliance에 필수.
• UIO는 strict ordering 완화. P2P·throughput 향상에 활용.
• Direct CXL.mem P2P는 *3.1+*에서 accel ↔ accel direct access 가능.

#다음 편

Ch 7: CXL.cache — D2H·H2D 흐름과 coherency state에서 디바이스가 host 메모리를 캐시하는 CXL.cache 프로토콜의 메시지 흐름을 본격적으로 분해합니다.

#관련 항목

• Ch 2: System Architecture
• Ch 14: Security — IDE·SPDM·TSP — DOE 위의 SPDM·IDE_KM 흐름
• Embedded Security Ch 12: SPDM과 CMA 인증 흐름
• Modern Embedded Recipes Ch 149: PCIe → CXL 진화

#시리즈 자료 출처 안내

본 글은 CXL Consortium·DMTF 공개 자료·Linux drivers/cxl/ 소스를 1차 자료로 합니다. CXL 4.0 Specification은 § navigation aid로만 인용. 자세한 spec 인용 정책은 Ch 1 footer 참고.