[CXL] 2. CLX System Architecture - part 2
2.3 CXL Type 3 Device
CXL Type 3 장치는 CXL.io 및 CXL.mem 프로토콜을 지원합니다. Figure 2-6에 나와 있는 것처럼 CXL Type 3 장치의 예는 호스트용 HDM-H 메모리 확장기입니다.
이 장치는 호스트 메모리에서 작동하는 전통적인 가속기가 아니기 때문에, 이 장치는 CXL.cache를 통해 어떠한 요청도 수행하지 않습니다. 수동 메모리 확장 장치는 일반적으로 메모리 내용을 직접 조작하지 않으며 메모리가 호스트에 노출될 때 (RAS 및 보안 요구 사항을 위한 예외가 있음) HDM-H 메모리 영역을 사용합니다. 이 장치는 주로 호스트에서 전송된 요청을 처리하기 위해 CXL.mem을 통해 작동합니다. CXL.io 프로토콜은 장치 탐지, 열거, 오류 보고 및 관리에 사용됩니다. 또한 CXL.io 프로토콜은 장치에서 다른 I/O 특정 응용 프로그램 용도에도 사용할 수 있습니다. CXL 아키텍처는 메모리 기술과 독립적이며 호스트에서 구현된 지원에 따라 다양한 메모리 구성 가능성을 허용합니다. HDM-DB로 노출된 메모리를 가진 Type 3 장치는 Section 2.2.1에서 설명된 것처럼 Type 2 장치용 일관성 사용을 동일하게 허용하며, HDM-H에 표시된 것 외에도 Type 3 장치에는 내부 장치 일관성 엔진(DCOH)이 포함되어야 합니다. HDM-DB 메모리를 사용하면 장치가 가속기로 동작하도록 허용하며 (이중 메모리 컴퓨팅의 한 변형), CXL.io 또는 CXL.mem에서 UIO를 사용하여 동료에게 직접 액세스할 수 있도록 합니다(3.3.2.1 절 참조).
2.4 Multi Logical Device (MLD)
타입 3 다중 논리 장치 (MLD)는 최대 16개의 격리된 논리 장치로 자원을 분할할 수 있습니다. 각 논리 장치는 CXL.io 및 CXL.mem 프로토콜에서 논리 장치 식별자 (LD-ID)로 식별됩니다. 가상 계층 (VH)에서 볼 수 있는 각 논리 장치는 타입 3 장치로 작동합니다. LD-ID는 VH에 액세스하는 소프트웨어에는 투명하며, 모든 LD에 대해 각 프로토콜에 대한 공통 트랜잭션 및 링크 레이어를 MLD 구성 요소가 갖고 있습니다. LD-ID 기능이 CXL.io 및 CXL.mem 프로토콜에만 존재하기 때문에 MLD는 제약으로 인해 타입 3 장치에만 사용됩니다.
MLD 구성 요소는 패브릭 매니저 (FM)를 위해 하나의 LD를 예약하고 호스트 바인딩에 최대 16개의 LD를 사용할 수 있습니다. FM 소유의 LD (FMLD)를 사용하여 FM은 LD 간의 자원 할당을 구성하고 여러 가상 CXL 스위치 (VCS)와 공유하는 물리적 링크를 관리할 수 있습니다. FMLD의 버스 마스터링 기능은 오류 메시지를 생성하는 데로 제한됩니다. 이 기능에서 생성된 오류 메시지는 반드시 FM으로 라우팅되어야 합니다.
MLD 구성 요소에는 FM만 접근할 수 있고 CXL LD-ID TLP Prefix에서 LD-ID로 FFFFh를 가진 요청에 의해 주소 지정 가능한 하나의 MLD DVSEC(8.1.10 절 참조)가 포함되어 있습니다. 스위치 구현은 FM만이 LD-ID FFFFh를 사용할 수 있는 유일한 엔터티임을 보장해야 합니다.
MLD 구성 요소는 FM API를 사용하여 LD를 구성하거나 정적으로 LD를 구성할 수 있습니다. 이 두 구성에서 구성된 LD 자원 할당은 MLD DVSEC를 통해 공지됩니다. 또한, MLD DVSEC의 FMLD의 LD-ID Hot Reset Vector 레지스터는 CXL 스위치가 하나 이상의 LD의 핫 리셋을 트리거하는 데에도 사용됩니다. 자세한 내용은 8.1.10.2 절을 참조하십시오.
2.4.1 LD-ID for CXL.io and CXL.mem
LD-ID는 CXL.io 및 CXL.mem 요청 및 응답에 적용되는 16비트 논리 장치 식별자입니다. MLD를 대상으로 하는 모든 요청 및 MLD에서 반환하는 모든 응답은 LD-ID를 포함해야 합니다. CXL.mem 헤더 서식을 LD-ID 필드를 운반하기 위한 것으로 참조하려면 3.3.5절 및 3.3.6절을 참조하십시오.
2.4.1.1 LD-ID for CXL.mem
CXL.mem은 LD-ID의 하위 4비트만 지원하며, 따라서 링크를 통해 최대 16개의 고유 LD-ID 값을 지원할 수 있습니다. MLD 포트를 통해 전달된 요청 및 응답은 LD-ID로 태그됩니다.
2.4.1.2 LD-ID for CXL.io
CXL.io는 MLD 포트를 통해 전달된 모든 요청 및 응답에 대해 16비트의 LD-ID를 운반하는 것을 지원합니다. LD-ID FFFFh는 예약되어 있으며 항상 FM에 의해 사용됩니다.
CXL.io는 16비트의 LD-ID 값을 전달하기 위해 Vendor Defined Local TLP Prefix를 활용합니다. Vendor Defined Local TLP Prefix의 형식은 다음과 같습니다. CXL LD-ID Vendor Defined Local TLP Prefix는 VendPrefixL0 Local TLP Prefix 유형을 사용합니다.
2.4.2 Pooled Memory Device Configuration Registers
각 LD는 소프트웨어에서 하나 이상의 PCIe Endpoint (EP) 기능으로 볼 수 있습니다. LD Function은 모든 구성 레지스터를 지원하지만, 공통 링크 동작에 영향을 미치는 여러 제어 레지스터는 가상화되어 있으며 링크에 직접적인 영향을 미치지 않습니다. LD의 각 Function은 PCIe 기본 사양에서 설명된대로 configuration 레지스터를 구현해야 합니다. 그렇게 명시되지 않은 한, configuration 레지스터의 범위는 PCIe 기본 사양에 설명된 대로입니다. 예를 들어, 명령 레지스터의 Memory Space Enable (MSE) 비트는 기능이 메모리 공간에 응답하는 것을 제어합니다.
Table 2-2은 PCIe 기본 사양과 비교했을 때 수정된 동작을 보이는 레지스터 필드 세트를 나열합니다.
1. AER - MLD 전체에 대한 이벤트가 복구할 수 없는 경우 모든 LD에 걸쳐 보고되어야 합니다. 이 이벤트가 특정 LD에 대한 것이면 해당 LD로 격리되어야 합니다.
2.4.3 Pooled Memory and Shared FAM (Host : HDM = 1:1)
여러 호스트를 지원하는 장치에서 노출된 Host-managed Device Memory (HDM)를 Fabric Attached Memory (FAM)이라고 합니다. LD-FAM으로 알려진 LD를 통해 노출된 FAM은 Port Based Routing (PBR) 링크를 사용하여 더 확장 가능한 방식으로 노출된 FAM은 Global-FAM (G-FAM)이라고 합니다.
하나의 HDM 영역이 단일 호스트 인터페이스에 전용되는 FAM을 "pooled memory" 또는 "pooled FAM"이라고 합니다. 여러 호스트 인터페이스가 동시에 단일 HDM 영역에 액세스하도록 구성된 FAM은 "Shared FAM"으로 알려져 있으며, 서로 다른 Shared FAM 영역은 서로 다른 호스트 인터페이스 집합을 지원하도록 구성될 수 있습니다.
LD-FAM에는 여러 장치 변형이 포함되어 있습니다. Multi-Logical Device (MLD)는 하나의 공유 링크를 통해 여러 LD를 노출합니다. Multi-headed Single Logical Device (MH-SLD)는 각각 전용 링크를 가진 여러 LD를 노출합니다. Multi-headed MLD (MH MLD)는 여러 링크를 포함하며 각 링크는 MLD 또는 SLD 작업을 지원하며(선택적으로 구성 가능), 적어도 하나의 링크는 MLD 작업을 지원합니다. 추가 세부 정보는 "2.5절, "Multi Headed Device"를 참조하십시오.
G-FAM 장치 (GFD)는 현재 하나 이상의 링크를 지원하는 아키텍처로 설계되어 있으며, 들어오는 CXL.mem 또는 UIO 요청의 호스트 인터페이스는 PBR 메시지에 포함된 Source PBR ID (SPID) 필드에 의해 결정됩니다(추가 세부 정보는 7.7.2절을 참조하십시오).
MH-SLD와 MH-MLD는 9.11.7.2절에 설명된 것과 같이 여러 CPU 토폴로지를 지원하는 단일 OS 도메인에서 여러 포트를 가진 임의의 Type 3 구성 요소와 구별되어야 합니다.
2.4.4 Coherency(일관성) Models for Shared FAM
각 공유 HDM-DB 영역의 일관성 모델은 FM에 의해 다중 호스트 하드웨어 일관성 또는 소프트웨어 관리 일관성 중 하나로 지정됩니다.
다중 호스트 하드웨어 일관성은 각 cacheline에 대해 MLD 하드웨어가 Table 3-37에서 정의된대로 각 호스트 일관성 상태를 어느 정도까지 추적해야 하는지를 의미합니다. 이는 MLD의 구현별 추적 메커니즘에 따라 다양한 정도로 구현될 수 있는데, 이는 일반적으로 스눕 필터 또는 전체 디렉터리로 분류될 수 있습니다. 각 호스트는 cacheline에 대한 Exclusive 액세스를 획득하여 해당 캐시 내에서 지원하는 임의의 원자 연산을 수행할 수 있습니다. 데이터는 캐시 일관성을 통해 전역적으로 관찰되며 보통 하드웨어 캐시 대퇴 흐름을 따릅니다. 이 메모리 영역으로의 MemWr 명령은 데드락을 방지하기 위해 SnpType 필드를 No Op로 설정해야 하며, 이는 호스트가 MemWr을 발행하기 전에 M2S Request 채널을 통해 소유권을 획득해야 하는 요구사항이며, 이로 인해 쓰기를 완료하기 위해 2 단계가 필요합니다. 이는 Shared FAM 및 Direct P2P CXL.mem에서의 하드웨어 일관성 모델에서 필요한 사항이며(공유되지 않은 HDM-DB 영역 및 단일 호스트 루트 포트에 할당된 영역과 달리 단일 단계 스눕이 가능한 Writes를 사용할 수 있음), 이를 통해 데드락을 방지합니다.
Shared FAM은 메모리를 단순한 HDM-H로 호스트에 노출할 수도 있지만, 이는 호스트 간의 소프트웨어 일관성 모델만을 지원합니다.
소프트웨어 관리 일관성은 MLD 하드웨어가 호스트 일관성 상태를 추적할 필요가 없습니다. 대신, 각 호스트의 소프트웨어는 각 cacheline의 소프트웨어 소유를 조정하기 위한 소프트웨어별 메커니즘을 사용합니다. 소프트웨어는 소프트웨어 관리 일관성 HDM 영역에서 cacheline의 소프트웨어 소유를 조정하기 위해 다른 HDM 영역에서의 다중 호스트 하드웨어 일관성에 의존할 수 있습니다. cacheline 소유를 조정하기 위한 소프트웨어의 다른 메커니즘은 이 명세의 범위를 벗어납니다.
IMPLEMENTATION NOTE
소프트웨어 관리 일관성은 소프트웨어가 캐시 계층을 무효화하고/또는 비우기 위한 메커니즘을 갖추고 있으며 로컬 소프트웨어에 의해 명시적으로 수행된 cacheline 수정에 따른 쓰기백만을 기다리고 있습니다. 성능 최적화를 위해 많은 프로세서는 소프트웨어가 프리페치 알고리즘을 직접 제어하지 않고 데이터를 프리페치합니다. 다양한 구현별 이유로 인해 일부 캐싱 에이전트는 하드웨어에 의해 프리페치된 clean cacheline을 스토어 명령 실행 없이 수정되지 않은 채로 쓰기백할 수 있습니다(예: E에서 M 상태로의 스토어 명령 실행 없이 승격). 호스트나 장치의 캐싱 에이전트 중에서 해당 cacheline을 읽기만 하려고 했던 캐시 에이전트의 clean 쓰기백은 해당 cacheline에 대한 쓰기를 실행한 호스트나 장치에 의해 수행된 업데이트를 덮어쓸 수 있습니다. 이는 소프트웨어 관리 일관성을 깨뜨립니다. 제로 길이의 쓰기 트랜잭션으로 인한 쓰기백은 clean 쓰기백으로 간주되지 않습니다. 또한 호스트나 장치는 내부 cacheline 크기가 64바이트보다 큰 경우가 있을 수 있으며, 쓰기백이 완료되기 위해 여러 CXL 쓰기를 필요로 할 수 있습니다. 이러한 CXL 쓰기 중 하나라도 소프트웨어 수정된 데이터를 포함하면 쓰기백은 clean으로 간주되지 않습니다.
소프트웨어 관리 일관성 체계는 해당 호스트나 장치의 어떠한 캐싱 에이전트도 clean 쓰기백을 생성하지 않음을 보장하는 경우에 복잡해집니다. "No Clean Writebacks" 능력 비트는 호스트용으로는 CXL 시스템 설명 구조(CSDS; 9.18.1.6절 참조) 또는 장치용으로는 DVSEC CXL Capability2 레지스터(8.1.3.7절 참조)에서 사용 가능하며, 이 비트를 설정하면 해당하는 캐싱 에이전트는 clean 쓰기백을 절대로 생성하지 않을 것을 보장합니다. 역호환성을 위해 이 비트가 해제된 경우에도 연관된 캐싱 에이전트가 반드시 clean 쓰기백을 생성한다는 것을 의미하지는 않습니다. 이 비트가 특정 Shared FAM 범위에 액세스할 수 있는 모든 캐싱 에이전트에 대해 설정되면 해당 범위를 대상으로 하는 소프트웨어 관리 일관성 프로토콜이 신뢰성 있는 결과를 제공할 수 있습니다. 이 비트는 하드웨어 일관성 메모리 범위에 대해 소프트웨어에 의해 무시되어야 합니다.
2.5 Multi-Headed Device
여러 CXL 포트를 갖는 Type 3 장치는 Multi-Headed Device로 간주됩니다. 각 포트는 "head"로 지칭됩니다. 각 head에서 자신을 어떻게 표시하는지에 따라 두 가지 유형의 Multi-Headed Device가 있습니다:
- MH-SLD(Multi-Headed Single Logical Device): 모든 head에서 SLD를 표시합니다.
- MH-MLD(Multi-Headed Multi-Logical Device): 자체 head 중 어느 것이든지 MLD를 표시할 수 있습니다.
Multi-Headed Devices의 head 관리는 해당 head에서 제시된 장치 모델을 따릅니다:
- SLD를 표시하는 head는 SLD에 사용 가능한 포트 관리 및 제어 기능을 지원할 수 있습니다.
- MLD를 표시하는 head는 MLD에 사용 가능한 포트 관리 및 제어 기능을 지원할 수 있습니다.
Multi-Headed Devices에서의 메모리 자원 관리는 MLD 구성 요소에 정의된 모델을 따릅니다. 이는 MH-SLD와 MH-MLD 모두가 메모리 자원, 상태, 컨텍스트 및 관리의 격리를 LD 단위로 지원해야 하기 때문입니다. 장치 내의 LD는 단일 head에 매핑됩니다.
- MH-SLD에서는 head와 LD 간에 1:1 매핑이 있습니다.
- MH-MLD에서는 여러 LD가 최대 하나의 head에 매핑됩니다. Multi Headed Device의 head는 적어도 하나 이상의 LD가 매핑되어야 하며, 최대 16개의 LD가 매핑될 수 있습니다. 하나의 LD가 매핑된 head는 자체를 SLD로 표시하고, 여러 개의 LD가 매핑된 head는 자체를 MLD로 표시해야 합니다. 각 head는 다른 수의 LD가 매핑될 수 있습니다.
Figure 2-7 및 Figure 2-8은 각각 MH-SLD 및 MH-MLD의 LD를 head에 매핑하는 그림을 나타냅니다.
Multi-Headed Devices는 장치 내의 모든 LD를 관리하기 위한 전용 Component Command Interface (CCI)인 LD Pool CCI를 노출해야 합니다. LD Pool CCI는 MCTP 기반 CCI로 노출되거나, Section 7.6.7.3.1에 자세히 설명된 대로 head의 Mailbox CCI를 통해 Tunnel Management Command 명령을 통해 액세스될 수 있습니다. LD Pool CCI는 장치 내의 모든 LD에 대한 관리 명령을 터널링하기 위해 Tunnel Management Command를 지원해야 합니다.
Multi-Headed Device에서 보고된 지원하는 head의 수는 일정해야 합니다. 특허 기구를 지원하는 장치(예: 2 x8 포트의 동적 분할을 단일 x16 head로 다시 구성하는 등)는 지원하는 head의 최대 수를 보고해야 합니다.
2.5.1 LD Management in MH-MLDs
MH-MLD의 LD Pool은 16개 이상의 LD를 지원할 수 있습니다. MH-MLD의 head를 통해 노출된 MLD는 해당 head에 매핑된 LD 수인 n을 기준으로 LD-IDs를 0에서 n-1까지 사용하며, MH-MLD는 head에서 받은 LD-IDs를 장치 전체의 LD 인덱스로 매핑합니다. MH MLD의 각 head 내의 FMLD는 해당 head에 매핑된 LD만 노출하고 관리해야 합니다.
Head 내의 LD 또는 FMLD는 Section 7.6.7.3.1에 자세히 설명된대로 Tunnel Management 명령을 사용하여 LD Pool CCI에 액세스함으로써 장치 내의 모든 LD를 볼 수 있고 관리할 수 있을 수 있습니다.
2.7 CXL Fabric
CXL Fabric은 확장 가능한 스위칭과 고급 스위칭 토폴로지를 지원하기 위해 Port Based Routing (PBR) 메시지와 플로우에 의존하는 기능을 설명합니다. PBR은 각 패브릭에서 최대 4096개의 PID를 지원하는 유연한 저지연 아키텍처를 가능하게 합니다. G-FAM 장치 연결(2.8절 참조)은 패브릭에 네이티브로 지원됩니다. 호스트와 장치는 패브릭 내의 Edge Switch를 통해 PBR 형식으로 번역된 표준 메시징 플로우를 사용합니다. 7.7절에서는 요구 사항 및 사용 사례를 정의합니다.
CXL Fabric은 각각 PBR을 지원하고 PBR 링크로 연결된 하나 이상의 스위치 집합입니다. 도메인은 단일 일관된 호스트 물리 주소 (HPA) 공간 내에서의 호스트 포트 및 장치의 집합입니다. CXL Fabric은 하나 이상의 호스트 포트를 각 도메인 내의 장치에 연결합니다.
2.8 Global FAM (G-FAM) Type 3 Device
G-FAM 장치(GFD)는 PBR 링크를 사용하여 CXL Fabric에 연결되는 Type 3 장치로, PBR 메시지 형식을 활용하여 LD-FAM 장치와 비교하여 훨씬 더 높은 확장성을 제공합니다. 관련 FM API는 8.2.9.9.10절에서 문서화되어 있으며 호스트 메일박스 인터페이스 세부 정보는 7.7.14절에서 제공됩니다.
LD-FAM 장치와 마찬가지로 GFD(G-FAM Device)도 pooled FAM, Shared FAM 또는 둘 다를 지원할 수 있습니다. GFD는 용량 관리를 위해 오로지 Dynamic Capacity 메커니즘에 의존합니다. 자세한 내용 및 LD-FAM 장치와의 다른 비교 사항은 7.7.2.3절을 참조하세요.
2.9 Manageability Overview
다양한 유형의 관리 시스템을 지원하기 위해 CXL은 여러 유형의 관리 인터페이스 및 관리 상호연결을 지원합니다. 일부는 외부 표준에 의해 정의되어 있으며, 일부는 CXL 명세에서 정의되어 있습니다.
CXL 구성 요소의 발견, 열거 및 기본 구성은 PCI-SIG 및 CXL 명세에 의해 정의됩니다. 이러한 기능들은 Configuration Space 구조 및 관련된 MMIO(Memory-Mapped I/O) 구조에 대한 액세스를 통해 수행됩니다.
보안 인증 및 데이터 무결성/암호화 관리는 PCI-SIG, DMTF 및 CXL 명세서에서 정의됩니다. 관련된 관리 트래픽은 Configuration Space를 사용하는 Data Object Exchange (DOE)를 통해 전송되거나 MCTP 기반 전송을 통해 전송될 수 있습니다. 후자는 PCIe VDM(Vendor Defined Message)을 사용하여 인밴드로 작동하거나, SMBus, I3C 또는 전용 PCIe 링크와 같은 관리 상호연결을 사용하여 아웃오브밴드로 작동할 수 있습니다.
CXL 장치의 관리 모델은 9.19절에서 다루고 있습니다. 고급 CXL 특정 구성 요소 관리는 하나 이상의 CCIs를 사용하여 처리되며, 이에 대한 내용은 9.20절에서 다루고 있습니다. CCI 명령은 4개의 큰 집합으로 나뉩니다:
- 일반 구성 요소 명령 (Generic Component commands)
- 메모리 장치 명령 (Memory Device commands)
- FM API 명령 (FM API commands)
- 공급 업체별 명령 (Vendor Specific commands)
이 4개의 집합은 8.2.9절에서 구체적으로 다루고 있습니다:
- 명령 및 능력 결정 (Command and capability determination)
- 명령의 foreground 및 background 작동 (Command foreground and background operation)
- 이벤트 로깅, 통지 및 로그 검색 (Event logging, notification, and log retrieval)
- 구성 요소가 여러 CCIs를 가지고 있는 경우의 상호 작용 (Interactions when a component has multiple CCIs)
각 명령은 구성 요소 유형 및 기타 속성에 따라 의무적, 선택적 또는 금지적입니다. 명령은 장치, 스위치 또는 둘 다에게 전송될 수 있습니다.
CCIs는 작업을 수행하기 위해 여러 전송 및 상호 연결을 사용합니다. 메일박스 메커니즘은 8.2.8.4절에서 다루어지며, 메일박스는 구조화된 MMIO 레지스터 인터페이스를 통해 액세스됩니다. MCTP 기반 전송은 PCIe VDM을 인밴드로 사용하거나 앞서 언급된 아웃오브밴드 관리 상호연결 중 하나를 사용할 수 있습니다. FM API 명령은 CXL 스위치를 통해 MLD 및 GFD로 터널링될 수 있습니다. 구성 및 MMIO 액세스는 CXL 스위치를 통해 MLD 내의 LD로 터널링될 수 있습니다.
DMTF의 플랫폼-레벨 데이터 모델 (PLDM)은 플랫폼 모니터링 및 제어에 사용되며, 구성 요소 펌웨어 업데이트에 사용될 수 있습니다. PLDM은 대상 CXL 구성 요소와 통신하기 위해 MCTP를 사용할 수 있습니다.
CXL가 여러 관리 표준 및 상호 연결을 사용하고 있기 때문에 CXL 구성 요소를 통합하는 시스템을 설계할 때 상호 운용성을 고려하는 것이 중요합니다.