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

#한 줄 요약

“CXL.io는 PCIe의 enumeration·configuration·MMIO·DMA·오류 보고를 그대로 씁니다.” — CXL에 특유한 부분은 디바이스가 CXL 기능을 알리는 DVSEC과, Compliance·CDAT 같은 메시지를 주고받는 DOE mailbox입니다. CXL 1.1부터 정의됐고 모든 CXL 디바이스에 필수입니다.

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

#CXL.io가 하는 일

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

PCIe 시맨틱을 그대로 쓰므로 기존 host의 PCIe enumeration 코드가 CXL 디바이스를 PCIe 디바이스로 발견합니다.

#CXL.io = PCIe + DVSEC + DOE

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

이 장은 이 둘을 중심으로 봅니다.

#DVSEC — CXL 호환 표지

*DVSEC (Designated Vendor-Specific Extended Capability)*은 PCIe가 정의한 capability입니다. CXL 규격은 Vendor ID를 1E98h로 둔 DVSEC들로 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로 확인합니다. pciutils는 Vendor 1e98 DVSEC을 CXL로 해석해 capability 필드를 풀어 보여 줍니다.

1
$ lspci -vvv -s 5e:00.0
2
    Capabilities: [...] Designated Vendor-Specific: Vendor=1e98 ID=0000 Rev=1 Len=56: CXL
3
        CXLCap: Cache- IO+ Mem+ MemHWInit+ HDMCount 1 Viral-
4
        ...

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

#DOE — Boutique Protocol Mailbox

*DOE (Data Object Exchange)*는 config space를 통해 데이터 객체를 주고받는 PCIe mailbox입니다.

CXL 규격(3.1 표 8-3)이 정의한 DOE Type은 Vendor ID 1E98h를 씁니다.

인증·measurement에 쓰는 SPDM은 DMTF가 정의한 프로토콜이고, CXL.cachemem IDE의 키 관리는 CXL_IDE_KM 프로토콜로 합니다(Ch 14 Security).

lspci는 DOE capability의 레지스터 상태를 보여 줍니다. 지원 프로토콜 목록은 DOE discovery로 따로 조회해야 합니다.

1
$ lspci -vvv -s 5e:00.0
2
    Capabilities: [...] Data Object Exchange
3
        DOECap: IntSup-
4
        DOECtl: IntEn-
5
        DOESta: Busy- IntSta- Error- ObjectReady-

DOE가 없어도 기본 CXL.io 동작은 가능하지만, CDAT 조회나 Compliance·인증 흐름에는 DOE가 필요합니다.

#UIO — Unordered I/O

*UIO (Unordered I/O)*는 PCIe의 기본 ordering 규칙에 묶이지 않는 I/O 요청입니다. CXL 3.x는 UIO를 peer-to-peer와 PBR fabric에서 씁니다. 예를 들어 PBR fabric에서 UIO 요청을 보낸 쪽은 *Source PBR ID(SPID)*로 구분됩니다.

순서 보장이 필요한 control path는 기본 PCIe ordering을 씁니다. CXL 4.0의 Streamlined Port는 UIO에 최적화돼 있습니다(Ch 5).

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

CXL 3.1 규격에는 디바이스끼리 host를 거치지 않고 메모리에 접근하는 경로가 두 가지 있습니다.

HDM-DB 영역이면 일관성은 BISnp로 맞춥니다(Ch 3). GPU·NPU 간 모델 weight·KV cache 공유가 이런 경로의 대표적인 쓰임입니다.

#Linux 측 — CXL.io 인식 경로

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

1
# 1. PCIe enumeration 결과
2
$ lspci -nn | grep -i cxl
3
5e:00.0 CXL [0502]: ... [1234:5678]     # class 05 subclass 02, prog-if 10 = CXL Memory Device
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. 메모리 장치의 보안 상태 (sysfs-bus-cxl ABI)
13
$ ls /sys/bus/cxl/devices/mem0/security/
14
erase  sanitize  state  ...

Type 3 메모리 장치는 cxl_pci 드라이버가 CXL memory class code로 잡고, CXL DVSEC을 찾아 설정을 읽습니다(drivers/cxl/pci.c). host bridge와 메모리 window는 cxl_acpi가 CEDT로 찾습니다.

#자주 하는 실수

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

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

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

DOE 객체는 Vendor ID와 Data Object Type으로 구분됩니다. CXL 규격이 정의한 Type은 Compliance(0)와 Table Access(2)이고, SPDM은 DMTF가 정의합니다. 디바이스는 자기가 지원하는 Type만 처리합니다.

#“UIO 항상 켜는 게 좋다”

UIO는 ordering을 보장하지 않으므로, 순서가 필요한 path에는 쓰면 안 됩니다.

#“P2P CXL.mem은 host overhead 0”

host를 거치지 않을 뿐, switch 통과와 (HDM-DB면) BISnp 일관성 트래픽은 그대로 있습니다.

#“DOE mailbox는 빠르다”

DOE는 config space 접근으로 객체를 주고받는 control path입니다. bulk data는 DMA·MMIO로 보냅니다.

#정리

• CXL.io는 PCIe의 enumeration·config·MMIO·DMA·오류 보고를 그대로 씁니다.
• CXL 기능은 Vendor ID 1E98h DVSEC으로 알립니다. lspci는 이를 : CXL로 해석합니다.
• DOE는 config space mailbox입니다. CXL이 정의한 DOE Type은 Compliance(0)와 Table Access/CDAT(2)입니다.
• UIO는 ordering 없는 I/O 요청으로, P2P와 PBR fabric에서 씁니다.
• 디바이스 간 직접 접근은 Direct P2P CXL.mem과 UIO Direct P2P to HDM 두 경로가 있습니다.
• Linux에서 Type 3는 cxl_pci가 class code로 잡고 DVSEC을 읽습니다.

#다음 편

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 3.1·1.1 spec, Linux drivers/cxl/ 소스, pciutils 소스를 근거로 합니다. 시리즈 전체의 자료 정책은 Ch 1에 있습니다.