Reference Architecture for Multi-Tenant CXL Memory Disaggregation: Choosing Between Direct-Attach, Switched Pooling and Fabric Sharing
Hyperscale operators adopting CXL must decide whether tenant memory should stay on direct-attached Type 3 expanders (CXL 1.1/2.0), be pooled behind a single-level switch with Multi-Logical Devices (CXL 2.0), or be shared and dynamically reassigned across a fabric using Dynamic Capacity Devices (CXL 3.x). Each step adds capacity elasticity, but also more latency, a larger blast radius and more management dependencies. Interoperability and isolation should be anchored to the published specifications, not vendor claims: CXL 3.1/3.2 (IDE link encryption, TSP for confidential computing), PCIe 5.0/6.0 physical layers, DMTF SPDM 1.2+ for device attestation, DMTF Redfish plus the CXL Fabric Manager API for orchestration, and ACPI 6.5 CEDT/HMAT with CXL CDAT for exposing topology to the host OS.
Decision criteria (direct vs. pooled vs. fabric)
Keep memory direct-attached when per-host demand is predictable and tail latency is the primary SLO. Move to MLD pooling under a CXL 2.0 switch when fleet-wide stranded DRAM is material and workloads tolerate an extra switch hop. Consider CXL 3.x fabric/DCD sharing only when every host CPU, switch and device in the path claims 3.x feature support you have verified yourself (DCD, back-invalidate, multi-headed devices), and when your orchestrator can drive Fabric Manager API calls with transactional rollback.
Pre-implementation checklist
Collect, per SKU, the supported CXL spec revision and optional features; PCIe link width/speed and the retimer budget; the IDE mode (skid vs. containment) and key-management path; SPDM version and certificate chain; CDAT-reported latency/bandwidth; the BIOS CEDT/CFMWS window layout and interleave granularity; Linux CXL driver/cxl-cli version; and RAS reporting (poison, CPER, viral handling). Reject any component whose attestation or isolation feature you cannot test end to end before tenant onboarding.
Illustrative analytical scenario (not a measurement)
Rack of 16 hosts, one CXL 2.0 switch, 4 MLD expanders with 16 logical devices each. Tenants are bound 1:1 to LDs, and the link is IDE-protected with SPDM-attested devices. Failure handling: if a switch or expander fails, the FM marks the affected LDs offline, hosts receive poison or surprise-removal events, and the orchestrator evacuates or restarts the affected VMs on local-DRAM capacity reserved at roughly 1/N headroom. Roll out gradually: start with non-latency-critical tiers (caches, cold heaps), then expand only once error-rate and reassignment-time SLOs hold.
Technical FAQ: How do we verify that one tenant cannot read or retain another tenant's memory after a CXL capacity reassignment on cxlcloud-style infrastructure?
Treat isolation as a chain you verify link by link. (1) Attest each device with SPDM before binding, and pin the measured firmware. (2) Make sure the FM assigns the LD or DCD extent to exactly one host, then read the binding back through Redfish/FM API. (3) Require a sanitize or secure-erase command (CXL memory-device Sanitize/Secure Erase) or a verified zeroing pass before re-releasing capacity, and log its completion status. (4) Enable IDE on every link segment, and use TSP where confidential VMs are in scope. (5) In pre-production, run negative tests: attempt cross-host access, inject surprise removal, and confirm poison propagation. If any step fails, quarantine the extent and do not return it to the free pool.
Arquitetura de Referência para Desagregação de Memória CXL Multi-Tenant: Escolhendo entre Conexão Direta, Pooling Comutado e Compartilhamento em Fabric
Operadores hyperscale que adotam CXL precisam decidir se a memória dos tenants fica em expansores Type 3 conectados diretamente (CXL 1.1/2.0), em pool atrás de um switch de nível único com Multi-Logical Devices (CXL 2.0) ou compartilhada e realocada dinamicamente em fabric com Dynamic Capacity Devices (CXL 3.x). Cada etapa ganha elasticidade de capacidade, mas também acrescenta latência, amplia o raio de impacto de falhas e aumenta as dependências de gerenciamento. Interoperabilidade e isolamento devem se apoiar nas especificações publicadas, não em promessas de fornecedor: CXL 3.1/3.2 (criptografia de link IDE, TSP para computação confidencial), camadas físicas PCIe 5.0/6.0, DMTF SPDM 1.2+ para atestação, DMTF Redfish mais a CXL Fabric Manager API para orquestração, e ACPI 6.5 CEDT/HMAT com CXL CDAT para expor a topologia ao SO.
Critérios de decisão (direto vs. pool vs. fabric)
Mantenha conexão direta quando a demanda por host for previsível e a latência de cauda for o SLO principal. Migre para pooling MLD sob switch CXL 2.0 quando a DRAM ociosa na frota for relevante e as cargas tolerarem um salto de switch. Considere compartilhamento fabric/DCD do CXL 3.x somente quando cada CPU, switch e dispositivo do caminho declarar suporte 3.x verificado por você (DCD, back-invalidate, dispositivos multi-headed) e quando o orquestrador conseguir executar chamadas da FM API com rollback transacional.
Checklist pré-implementação
Levante, por SKU, a revisão da especificação CXL e os recursos opcionais; largura/velocidade do link PCIe e o orçamento de retimers; o modo IDE (skid vs. containment) e o caminho de gestão de chaves; versão SPDM e cadeia de certificados; latência/banda reportadas no CDAT; o layout das janelas CEDT/CFMWS e a granularidade de interleave; versão do driver CXL do Linux/cxl-cli; e o reporte RAS (poison, CPER, tratamento viral). Rejeite qualquer componente cuja atestação ou isolamento não possa ser testado de ponta a ponta antes de receber tenants.
Cenário analítico ilustrativo (não é medição)
Rack com 16 hosts, um switch CXL 2.0 e 4 expansores MLD com 16 LDs cada. Tenants ficam vinculados 1:1 a LDs, com link protegido por IDE e dispositivos atestados via SPDM. Tratamento de falhas: se um switch ou expansor falhar, o FM marca os LDs afetados como offline, os hosts recebem eventos de poison ou remoção surpresa e o orquestrador evacua ou reinicia as VMs em DRAM local reservada com folga de cerca de 1/N. Faça o rollout gradual: comece por camadas não críticas em latência (caches, heaps frios) e expanda somente quando os SLOs de taxa de erro e de tempo de realocação se mantiverem.
FAQ Técnica: Como verificar que um tenant não consegue ler nem reter a memória de outro tenant após uma realocação de capacidade CXL em uma infraestrutura no estilo do cxlcloud?
Trate o isolamento como uma cadeia verificada elo por elo. (1) Ateste cada dispositivo via SPDM antes do vínculo e fixe o firmware medido. (2) Garanta que o FM atribua o LD ou extent DCD a exatamente um host e confirme o vínculo lendo de volta via Redfish/FM API. (3) Exija um comando Sanitize/Secure Erase do dispositivo de memória CXL, ou uma passagem de zeramento verificada, antes de liberar a capacidade, e registre o status de conclusão. (4) Habilite IDE em todos os segmentos de link e use TSP quando houver VMs confidenciais. (5) Em pré-produção, rode testes negativos: tente acesso cruzado entre hosts, injete remoção surpresa e confirme a propagação de poison. Se qualquer etapa falhar, coloque o extent em quarentena e não o devolva ao pool livre.
Arquitectura de Referencia para la Desagregación de Memoria CXL Multi-Tenant: Cómo Elegir entre Conexión Directa, Pooling Conmutado y Compartición en Fabric
Los operadores hyperscale que adoptan CXL deben decidir si la memoria de los tenants permanece en expansores Type 3 de conexión directa (CXL 1.1/2.0), se agrupa detrás de un switch de un solo nivel con Multi-Logical Devices (CXL 2.0) o se comparte y reasigna dinámicamente en un fabric con Dynamic Capacity Devices (CXL 3.x). Cada paso aporta elasticidad de capacidad, pero también más latencia, un mayor radio de impacto y más dependencias de gestión. La interoperabilidad y el aislamiento deben basarse en las especificaciones publicadas, no en afirmaciones de los fabricantes: CXL 3.1/3.2 (cifrado de enlace IDE, TSP para computación confidencial), capas físicas PCIe 5.0/6.0, DMTF SPDM 1.2+ para atestación, DMTF Redfish junto con la CXL Fabric Manager API para orquestación, y ACPI 6.5 CEDT/HMAT con CXL CDAT para exponer la topología al sistema operativo.
Criterios de decisión (directo vs. pool vs. fabric)
Mantenga la conexión directa cuando la demanda por host sea predecible y la latencia de cola sea el SLO principal. Pase a pooling MLD bajo un switch CXL 2.0 cuando la DRAM varada en la flota sea significativa y las cargas toleren un salto de switch adicional. Considere la compartición fabric/DCD de CXL 3.x solo cuando cada CPU, switch y dispositivo de la ruta declare soporte 3.x que usted haya verificado (DCD, back-invalidate, dispositivos multi-headed) y el orquestador pueda ejecutar llamadas de la FM API con rollback transaccional.
Checklist previa a la implementación
Recopile, por SKU, la revisión de la especificación CXL y las funciones opcionales; ancho/velocidad del enlace PCIe y el presupuesto de retimers; el modo IDE (skid vs. containment) y la ruta de gestión de claves; versión SPDM y cadena de certificados; latencia/ancho de banda reportados en CDAT; la disposición de ventanas CEDT/CFMWS y la granularidad de interleave; versión del driver CXL de Linux/cxl-cli; y el reporte RAS (poison, CPER, manejo viral). Rechace cualquier componente cuya atestación o aislamiento no pueda probarse de extremo a extremo antes de incorporar tenants.
Escenario analítico ilustrativo (no es una medición)
Rack de 16 hosts, un switch CXL 2.0 y 4 expansores MLD con 16 LDs cada uno. Los tenants se vinculan 1:1 a LDs, con enlace protegido por IDE y dispositivos atestados mediante SPDM. Manejo de fallos: si falla un switch o un expansor, el FM marca los LDs afectados como offline, los hosts reciben eventos de poison o de extracción sorpresa y el orquestador evacúa o reinicia las VMs en DRAM local reservada con un margen de aproximadamente 1/N. Despliegue gradual: empiece por niveles no críticos en latencia (cachés, heaps fríos) y amplíe solo cuando se cumplan los SLOs de tasa de error y de tiempo de reasignación.
Preguntas Frecuentes Técnicas: ¿Cómo se verifica que un tenant no pueda leer ni retener la memoria de otro tenant tras una reasignación de capacidad CXL en una infraestructura tipo cxlcloud?
Trate el aislamiento como una cadena que se verifica eslabón por eslabón. (1) Ateste cada dispositivo con SPDM antes del vínculo y fije el firmware medido. (2) Asegúrese de que el FM asigne el LD o extent DCD a un único host y confirme el vínculo leyéndolo de vuelta vía Redfish/FM API. (3) Exija un Sanitize/Secure Erase del dispositivo de memoria CXL, o una pasada de borrado a ceros verificada, antes de liberar la capacidad, y registre su estado de finalización. (4) Active IDE en todos los segmentos del enlace y use TSP cuando haya VMs confidenciales. (5) En preproducción, ejecute pruebas negativas: intente accesos cruzados entre hosts, inyecte extracciones sorpresa y confirme la propagación de poison. Si algún paso falla, ponga el extent en cuarentena y no lo devuelva al pool libre.
Architecture de Référence pour la Désagrégation Mémoire CXL Multi-Tenant : Choisir entre Attachement Direct, Pooling Commuté et Partage sur Fabric
Les opérateurs hyperscale qui adoptent CXL doivent choisir où placer la mémoire des tenants : sur des extensions Type 3 en attachement direct (CXL 1.1/2.0), dans un pool derrière un switch à un seul niveau avec des Multi-Logical Devices (CXL 2.0), ou en partage avec réaffectation dynamique sur un fabric via des Dynamic Capacity Devices (CXL 3.x). Chaque étape gagne en élasticité de capacité, au prix d'une latence plus élevée, d'un rayon d'impact élargi et de dépendances de gestion supplémentaires. L'interopérabilité et l'isolation doivent reposer sur les spécifications publiées, et non sur les déclarations des fournisseurs : CXL 3.1/3.2 (chiffrement de lien IDE, TSP pour le confidential computing), couches physiques PCIe 5.0/6.0, DMTF SPDM 1.2+ pour l'attestation, DMTF Redfish et la CXL Fabric Manager API pour l'orchestration, et ACPI 6.5 CEDT/HMAT avec CXL CDAT pour exposer la topologie au système d'exploitation.
Critères de décision (direct vs. pool vs. fabric)
Conservez l'attachement direct lorsque la demande par hôte est prévisible et que la latence de queue est le SLO principal. Passez au pooling MLD sous un switch CXL 2.0 lorsque la DRAM inutilisée à l'échelle du parc est significative et que les charges tolèrent un saut de switch supplémentaire. N'envisagez le partage fabric/DCD de CXL 3.x que si chaque CPU, switch et périphérique du chemin annonce un support 3.x que vous avez vérifié (DCD, back-invalidate, périphériques multi-headed) et si l'orchestrateur sait piloter la FM API avec rollback transactionnel.
Checklist avant implémentation
Relevez, par SKU, la révision de la spécification CXL et les fonctions optionnelles ; la largeur/vitesse du lien PCIe et le budget de retimers ; le mode IDE (skid vs. containment) et le chemin de gestion des clés ; la version SPDM et la chaîne de certificats ; la latence/bande passante déclarées dans le CDAT ; la disposition des fenêtres CEDT/CFMWS et la granularité d'entrelacement ; la version du pilote CXL Linux/cxl-cli ; et le reporting RAS (poison, CPER, gestion virale). Écartez tout composant dont l'attestation ou l'isolation ne peut pas être testée de bout en bout avant l'accueil des tenants.
Scénario analytique illustratif (pas une mesure)
Baie de 16 hôtes, un switch CXL 2.0 et 4 extensions MLD de 16 LD chacune. Chaque tenant est lié 1:1 à un LD, avec un lien protégé par IDE et des périphériques attestés via SPDM. Gestion des pannes : en cas de défaillance d'un switch ou d'une extension, le FM passe les LD concernés hors ligne, les hôtes reçoivent des événements de poison ou de retrait inopiné, et l'orchestrateur évacue ou redémarre les VM sur de la DRAM locale réservée avec une marge d'environ 1/N. Déploiement progressif : commencez par les niveaux peu sensibles à la latence (caches, heaps froids), puis étendez uniquement si les SLO de taux d'erreur et de temps de réaffectation sont tenus.
FAQ Technique: Comment vérifier qu'un tenant ne peut ni lire ni conserver la mémoire d'un autre tenant après une réaffectation de capacité CXL sur une infrastructure de type cxlcloud ?
Traitez l'isolation comme une chaîne à vérifier maillon par maillon. (1) Attestez chaque périphérique via SPDM avant liaison et figez le firmware mesuré. (2) Assurez-vous que le FM attribue le LD ou l'extent DCD à un seul hôte, puis confirmez la liaison en la relisant via Redfish/FM API. (3) Exigez un Sanitize/Secure Erase du périphérique mémoire CXL, ou une remise à zéro vérifiée, avant de libérer la capacité, et journalisez le statut d'achèvement. (4) Activez IDE sur chaque segment de lien et utilisez TSP lorsque des VM confidentielles sont concernées. (5) En préproduction, exécutez des tests négatifs : tentez un accès croisé entre hôtes, injectez un retrait inopiné et confirmez la propagation du poison. En cas d'échec à une étape, mettez l'extent en quarantaine et ne le remettez pas dans le pool libre.
Architettura di Riferimento per la Disaggregazione della Memoria CXL Multi-Tenant: Scegliere tra Collegamento Diretto, Pooling Commutato e Condivisione su Fabric
Gli operatori hyperscale che adottano CXL devono decidere se la memoria dei tenant resta su espansori Type 3 a collegamento diretto (CXL 1.1/2.0), viene messa in pool dietro uno switch a singolo livello con Multi-Logical Devices (CXL 2.0) oppure viene condivisa e riassegnata dinamicamente su un fabric tramite Dynamic Capacity Devices (CXL 3.x). Ogni passo aumenta l'elasticità della capacità, ma aggiunge latenza, allarga il raggio d'impatto dei guasti e introduce più dipendenze di gestione. Interoperabilità e isolamento vanno ancorati alle specifiche pubblicate, non alle dichiarazioni dei fornitori: CXL 3.1/3.2 (cifratura di link IDE, TSP per il confidential computing), livelli fisici PCIe 5.0/6.0, DMTF SPDM 1.2+ per l'attestazione, DMTF Redfish insieme alla CXL Fabric Manager API per l'orchestrazione, e ACPI 6.5 CEDT/HMAT con CXL CDAT per esporre la topologia al sistema operativo.
Criteri di decisione (diretto vs. pool vs. fabric)
Mantenete il collegamento diretto quando la domanda per host è prevedibile e la latenza di coda è lo SLO principale. Passate al pooling MLD sotto uno switch CXL 2.0 quando la DRAM inutilizzata a livello di flotta è rilevante e i carichi tollerano un salto di switch in più. Valutate la condivisione fabric/DCD di CXL 3.x solo se ogni CPU, switch e dispositivo del percorso dichiara un supporto 3.x che avete verificato (DCD, back-invalidate, dispositivi multi-headed) e se l'orchestratore sa eseguire chiamate FM API con rollback transazionale.
Checklist pre-implementazione
Raccogliete, per SKU, la revisione della specifica CXL e le funzioni opzionali; larghezza/velocità del link PCIe e il budget di retimer; la modalità IDE (skid vs. containment) e il percorso di gestione delle chiavi; versione SPDM e catena di certificati; latenza/banda dichiarate nel CDAT; il layout delle finestre CEDT/CFMWS e la granularità di interleave; versione del driver CXL di Linux/cxl-cli; e il reporting RAS (poison, CPER, gestione virale). Scartate qualsiasi componente la cui attestazione o il cui isolamento non possa essere testato end-to-end prima dell'onboarding dei tenant.
Scenario analitico illustrativo (non è una misura)
Rack con 16 host, uno switch CXL 2.0 e 4 espansori MLD da 16 LD ciascuno. I tenant sono vincolati 1:1 ai LD, con link protetto da IDE e dispositivi attestati via SPDM. Gestione dei guasti: se uno switch o un espansore si guasta, il FM porta offline i LD interessati, gli host ricevono eventi di poison o di rimozione improvvisa e l'orchestratore evacua o riavvia le VM su DRAM locale riservata con un margine di circa 1/N. Rollout graduale: iniziate dai livelli non critici per la latenza (cache, heap freddi) ed estendete solo quando gli SLO di tasso di errore e di tempo di riassegnazione sono rispettati.
FAQ Tecnica: Come si verifica che un tenant non possa leggere né trattenere la memoria di un altro tenant dopo una riassegnazione di capacità CXL su un'infrastruttura di tipo cxlcloud?
Trattate l'isolamento come una catena da verificare anello per anello. (1) Attestate ogni dispositivo con SPDM prima del binding e bloccate il firmware misurato. (2) Assicuratevi che il FM assegni il LD o l'extent DCD a un solo host e confermate il binding rileggendolo via Redfish/FM API. (3) Richiedete un Sanitize/Secure Erase del dispositivo di memoria CXL, o un azzeramento verificato, prima di rilasciare la capacità, e registrate lo stato di completamento. (4) Abilitate IDE su ogni segmento di link e usate TSP quando sono coinvolte VM confidenziali. (5) In pre-produzione eseguite test negativi: tentate accessi incrociati tra host, iniettate una rimozione improvvisa e confermate la propagazione del poison. Se un passo fallisce, mettete l'extent in quarantena e non restituitelo al pool libero.
Referenzarchitektur für mandantenfähige CXL-Speicherdisaggregation: Auswahl zwischen Direktanbindung, geswitchtem Pooling und Fabric-Sharing
Hyperscale-Betreiber, die CXL einführen, müssen entscheiden, ob Mandantenspeicher auf direkt angebundenen Type-3-Expandern (CXL 1.1/2.0) bleibt, hinter einem einstufigen Switch mit Multi-Logical Devices (CXL 2.0) gepoolt wird oder über eine Fabric mit Dynamic Capacity Devices (CXL 3.x) geteilt und dynamisch neu zugewiesen wird. Jede Stufe bringt mehr Kapazitätselastizität, aber auch mehr Latenz, einen größeren Fehlerradius und zusätzliche Management-Abhängigkeiten. Interoperabilität und Isolation sollten auf den veröffentlichten Spezifikationen beruhen, nicht auf Herstellerangaben: CXL 3.1/3.2 (IDE-Link-Verschlüsselung, TSP für Confidential Computing), PCIe-5.0/6.0-Bitübertragungsschichten, DMTF SPDM 1.2+ für die Attestierung, DMTF Redfish und die CXL Fabric Manager API für die Orchestrierung sowie ACPI 6.5 CEDT/HMAT mit CXL CDAT, um die Topologie für das Betriebssystem sichtbar zu machen.
Entscheidungskriterien (direkt vs. Pool vs. Fabric)
Bleiben Sie bei der Direktanbindung, wenn der Bedarf pro Host vorhersagbar ist und die Tail-Latenz das primäre SLO darstellt. Wechseln Sie zu MLD-Pooling hinter einem CXL-2.0-Switch, wenn flottenweit ungenutzter DRAM ins Gewicht fällt und die Workloads einen zusätzlichen Switch-Hop tolerieren. Ziehen Sie CXL-3.x-Fabric/DCD-Sharing nur in Betracht, wenn jede CPU, jeder Switch und jedes Gerät im Pfad eine von Ihnen selbst verifizierte 3.x-Unterstützung ausweist (DCD, Back-Invalidate, Multi-Headed Devices) und der Orchestrator FM-API-Aufrufe mit transaktionalem Rollback ausführen kann.
Checkliste vor der Implementierung
Erfassen Sie pro SKU die CXL-Spezifikationsrevision und die optionalen Funktionen; PCIe-Linkbreite/-geschwindigkeit und das Retimer-Budget; den IDE-Modus (Skid vs. Containment) und den Schlüsselverwaltungspfad; SPDM-Version und Zertifikatskette; die im CDAT gemeldete Latenz/Bandbreite; das Layout der CEDT/CFMWS-Fenster und die Interleave-Granularität; die Version des Linux-CXL-Treibers/cxl-cli; sowie das RAS-Reporting (Poison, CPER, Viral-Handling). Lehnen Sie jede Komponente ab, deren Attestierung oder Isolation sich vor dem Mandanten-Onboarding nicht durchgängig testen lässt.
Illustratives Analyseszenario (keine Messung)
Rack mit 16 Hosts, einem CXL-2.0-Switch und 4 MLD-Expandern mit je 16 LDs. Mandanten werden 1:1 an LDs gebunden, der Link ist IDE-geschützt und die Geräte sind per SPDM attestiert. Fehlerbehandlung: Fällt ein Switch oder Expander aus, setzt der FM die betroffenen LDs offline, die Hosts erhalten Poison- oder Surprise-Removal-Ereignisse, und der Orchestrator evakuiert oder startet die VMs auf lokalem DRAM neu, der mit etwa 1/N Reserve vorgehalten wird. Schrittweiser Rollout: Beginnen Sie mit nicht latenzkritischen Stufen (Caches, kalte Heaps) und erweitern Sie erst, wenn die SLOs für Fehlerrate und Neuzuweisungsdauer eingehalten werden.
Technische FAQ: Wie lässt sich verifizieren, dass ein Mandant nach einer CXL-Kapazitätsneuzuweisung auf einer Infrastruktur im Stil von cxlcloud den Speicher eines anderen Mandanten weder lesen noch zurückbehalten kann?
Behandeln Sie Isolation als Kette, die Glied für Glied verifiziert wird. (1) Attestieren Sie jedes Gerät vor der Bindung per SPDM und fixieren Sie die gemessene Firmware. (2) Stellen Sie sicher, dass der FM das LD oder den DCD-Extent genau einem Host zuweist, und bestätigen Sie die Bindung durch Rücklesen über Redfish/FM API. (3) Fordern Sie vor der Freigabe der Kapazität ein Sanitize/Secure Erase des CXL-Speichergeräts oder einen verifizierten Nullungsdurchlauf und protokollieren Sie den Abschlussstatus. (4) Aktivieren Sie IDE auf jedem Linksegment und setzen Sie TSP ein, wenn vertrauliche VMs betroffen sind. (5) Führen Sie in der Vorproduktion Negativtests durch: Versuchen Sie hostübergreifende Zugriffe, injizieren Sie ein Surprise Removal und bestätigen Sie die Poison-Propagation. Schlägt ein Schritt fehl, stellen Sie den Extent unter Quarantäne und geben Sie ihn nicht in den freien Pool zurück.
多租户 CXL 内存解耦参考架构：直连、交换池化与 Fabric 共享的选型
采用 CXL 的超大规模运营商需要决定租户内存的部署方式：留在直连的 Type 3 扩展器上（CXL 1.1/2.0），通过带 Multi-Logical Devices 的单级交换机进行池化（CXL 2.0），或者借助 Dynamic Capacity Devices 在 Fabric 上共享并动态重新分配（CXL 3.x）。每进一步都能提升容量弹性，但也会带来更高的延迟、更大的故障影响范围和更多的管理依赖。互操作性和隔离应以已发布的规范为依据，而不是厂商宣称：CXL 3.1/3.2（IDE 链路加密、面向机密计算的 TSP）、PCIe 5.0/6.0 物理层、用于设备证明的 DMTF SPDM 1.2+、用于编排的 DMTF Redfish 与 CXL Fabric Manager API，以及向操作系统暴露拓扑的 ACPI 6.5 CEDT/HMAT 与 CXL CDAT。
决策标准（直连 vs. 池化 vs. Fabric）
当每台主机的需求可预测、且尾延迟是首要 SLO 时，保持直连。当全机群闲置 DRAM 数量可观、且工作负载能容忍多一级交换机跳数时，转向 CXL 2.0 交换机下的 MLD 池化。只有当路径上每个 CPU、交换机和设备都声明支持且经您亲自验证的 3.x 功能（DCD、back-invalidate、multi-headed 设备），并且编排器能以事务性回滚方式调用 FM API 时，才考虑 CXL 3.x 的 Fabric/DCD 共享。
实施前检查清单
按 SKU 收集 CXL 规范版本与可选功能；PCIe 链路宽度/速率与 retimer 预算；IDE 模式（skid 或 containment）与密钥管理路径；SPDM 版本与证书链；CDAT 上报的延迟/带宽；BIOS 中 CEDT/CFMWS 窗口布局与交织粒度；Linux CXL 驱动/cxl-cli 版本；以及 RAS 上报能力（poison、CPER、viral 处理）。凡是证明或隔离功能无法在租户上线前完成端到端测试的组件，一律拒绝。
示例性分析场景（非实测）
一个机架有 16 台主机、1 台 CXL 2.0 交换机和 4 台 MLD 扩展器，每台 16 个 LD。租户与 LD 一对一绑定，链路启用 IDE 保护，设备经 SPDM 证明。故障处理：交换机或扩展器失效时，FM 将受影响的 LD 置为离线，主机收到 poison 或意外移除事件，编排器将受影响的虚拟机迁移或重启到本地 DRAM 上，本地 DRAM 预留约 1/N 的余量。分阶段上线：先从对延迟不敏感的层级（缓存、冷堆）开始，待错误率和重新分配耗时的 SLO 稳定达标后再扩大范围。
技术常见问题 (FAQ): 在 cxlcloud 类基础设施上进行 CXL 容量重新分配后，如何验证一个租户无法读取或残留另一个租户的内存？
把隔离当作一条链，逐环验证。(1) 绑定前用 SPDM 证明每个设备，并锁定已度量的固件。(2) 确保 FM 只将 LD 或 DCD extent 分配给一台主机，并通过 Redfish/FM API 回读确认绑定。(3) 在重新释放容量前，执行 CXL 内存设备的 Sanitize/Secure Erase 命令或经验证的清零操作，并记录完成状态。(4) 在所有链路段启用 IDE；涉及机密虚拟机时启用 TSP。(5) 在预生产环境中进行负向测试：尝试跨主机访问、注入意外移除，并确认 poison 能正确传播。任何一步失败，都应隔离该 extent，不得放回空闲池。
マルチテナント CXL メモリ分離のリファレンスアーキテクチャ：直結・スイッチ型プーリング・ファブリック共有の選定
CXL を導入するハイパースケール事業者は、テナントメモリを直結の Type 3 エクスパンダ（CXL 1.1/2.0）に置くか、Multi-Logical Devices を備えた単一階層スイッチの背後でプール化するか（CXL 2.0）、あるいは Dynamic Capacity Devices を用いてファブリック上で共有・動的再割り当てするか（CXL 3.x）を決める必要があります。段階が進むほど容量の弾力性は高まりますが、レイテンシ、障害の影響範囲、管理上の依存関係も増えます。相互運用性と分離の根拠は、ベンダーの主張ではなく公開仕様に置くべきです。具体的には、CXL 3.1/3.2（IDE リンク暗号化、コンフィデンシャルコンピューティング向け TSP）、PCIe 5.0/6.0 物理層、デバイス認証用の DMTF SPDM 1.2+、オーケストレーション用の DMTF Redfish と CXL Fabric Manager API、OS にトポロジを提示する ACPI 6.5 CEDT/HMAT と CXL CDAT です。
判断基準（直結 vs. プール vs. ファブリック）
ホストごとの需要が予測可能で、テールレイテンシが最重要 SLO であれば直結を維持します。フリート全体で遊休 DRAM が無視できない量になり、ワークロードがスイッチ 1 ホップの追加を許容できるなら、CXL 2.0 スイッチ配下の MLD プーリングに移行します。CXL 3.x のファブリック/DCD 共有は、経路上のすべての CPU・スイッチ・デバイスが表明する 3.x 機能（DCD、back-invalidate、multi-headed デバイス）を自社で検証済みであり、かつオーケストレータがトランザクショナルなロールバック付きで FM API を実行できる場合に限って検討します。
実装前チェックリスト
SKU ごとに、CXL 仕様リビジョンとオプション機能、PCIe リンク幅/速度とリタイマ予算、IDE モード（skid か containment か）と鍵管理経路、SPDM バージョンと証明書チェーン、CDAT が報告するレイテンシ/帯域、BIOS の CEDT/CFMWS ウィンドウ配置とインターリーブ粒度、Linux CXL ドライバ/cxl-cli のバージョン、RAS 報告（poison、CPER、viral 処理）を収集します。認証や分離の機能をテナント受け入れ前にエンドツーエンドで試験できないコンポーネントは採用しません。
例示的な分析シナリオ（実測ではありません）：16 ホスト、CXL 2.0 スイッチ 1 台、16 LD を持つ MLD エクスパンダ 4 台からなるラック。テナントは LD に 1
1 でバインドし、リンクは IDE で保護、デバイスは SPDM で認証済みとします。障害時の対応：スイッチやエクスパンダが故障すると、FM が該当 LD をオフラインにし、ホストは poison またはサプライズ取り外しのイベントを受け取り、オーケストレータは約 1/N の余裕を確保したローカル DRAM 上へ VM を退避または再起動します。段階的に展開し、まずレイテンシ要件の緩い層（キャッシュ、コールドヒープ）から始め、エラー率と再割り当て時間の SLO を満たし続けることを確認してから拡大します。
技術FAQ: cxlcloud 型のインフラで CXL 容量を再割り当てした後、あるテナントが別テナントのメモリを読み取ったり残留させたりできないことを、どう検証すればよいですか？
分離は鎖として捉え、一つずつ検証します。(1) バインド前に各デバイスを SPDM で認証し、測定済みファームウェアを固定します。(2) FM が LD または DCD エクステントを 1 台のホストにのみ割り当てていることを確認し、Redfish/FM API で読み戻してバインドを検証します。(3) 容量を再解放する前に、CXL メモリデバイスの Sanitize/Secure Erase コマンドまたは検証済みのゼロ化を必須とし、完了ステータスを記録します。(4) すべてのリンク区間で IDE を有効にし、コンフィデンシャル VM が対象なら TSP を使用します。(5) 本番前環境でネガティブテストを行います。ホスト間アクセスを試み、サプライズ取り外しを注入し、poison が正しく伝播することを確認してください。いずれかの手順が失敗した場合は、そのエクステントを隔離し、空きプールに戻さないでください。
멀티테넌트 CXL 메모리 분리 참조 아키텍처: 직접 연결, 스위치 기반 풀링, 패브릭 공유 중 선택하기
CXL을 도입하는 하이퍼스케일 운영자는 테넌트 메모리를 직접 연결된 Type 3 익스팬더(CXL 1.1/2.0)에 둘지, Multi-Logical Devices를 갖춘 단일 계층 스위치 뒤에서 풀링할지(CXL 2.0), 아니면 Dynamic Capacity Devices로 패브릭에서 공유하고 동적으로 재할당할지(CXL 3.x) 결정해야 합니다. 단계가 올라갈수록 용량 탄력성은 커지지만, 지연 시간과 장애 영향 범위, 관리 의존성도 함께 커집니다. 상호운용성과 격리는 벤더 주장이 아니라 공개된 사양에 근거해야 합니다. CXL 3.1/3.2(IDE 링크 암호화, 컨피덴셜 컴퓨팅용 TSP), PCIe 5.0/6.0 물리 계층, 디바이스 증명을 위한 DMTF SPDM 1.2+, 오케스트레이션을 위한 DMTF Redfish와 CXL Fabric Manager API, 그리고 OS에 토폴로지를 노출하는 ACPI 6.5 CEDT/HMAT와 CXL CDAT가 그 기준입니다.
결정 기준(직접 연결 vs. 풀링 vs. 패브릭)
호스트별 수요가 예측 가능하고 테일 지연 시간이 최우선 SLO라면 직접 연결을 유지하십시오. 플릿 전체에서 놀고 있는 DRAM이 상당하고 워크로드가 스위치 한 홉 추가를 감당할 수 있다면 CXL 2.0 스위치 아래 MLD 풀링으로 전환하십시오. CXL 3.x 패브릭/DCD 공유는 경로상의 모든 CPU, 스위치, 디바이스가 내세우는 3.x 기능(DCD, back-invalidate, multi-headed 디바이스)을 직접 검증했고, 오케스트레이터가 트랜잭션 롤백을 포함해 FM API를 호출할 수 있을 때만 고려하십시오.
구현 전 체크리스트
SKU별로 CXL 사양 리비전과 선택 기능, PCIe 링크 폭/속도와 리타이머 예산, IDE 모드(skid 또는 containment)와 키 관리 경로, SPDM 버전과 인증서 체인, CDAT가 보고하는 지연 시간/대역폭, BIOS의 CEDT/CFMWS 윈도우 배치와 인터리브 단위, Linux CXL 드라이버/cxl-cli 버전, RAS 보고(poison, CPER, viral 처리)를 수집하십시오. 증명이나 격리 기능을 테넌트 온보딩 전에 엔드투엔드로 시험할 수 없는 구성 요소는 채택하지 마십시오.
예시 분석 시나리오(실측 아님)
호스트 16대, CXL 2.0 스위치 1대, 각각 LD 16개를 가진 MLD 익스팬더 4대로 구성된 랙입니다. 테넌트는 LD에 1:1로 바인딩되고, 링크는 IDE로 보호되며, 디바이스는 SPDM으로 증명됩니다. 장애 처리: 스위치나 익스팬더에 장애가 나면 FM이 해당 LD를 오프라인으로 전환하고, 호스트는 poison 또는 예기치 않은 제거 이벤트를 받으며, 오케스트레이터는 약 1/N 여유를 확보해 둔 로컬 DRAM으로 VM을 대피시키거나 재시작합니다. 단계적으로 롤아웃하여 지연 시간에 덜 민감한 계층(캐시, 콜드 힙)부터 시작하고, 오류율과 재할당 시간 SLO가 유지되는 것을 확인한 뒤에 확대하십시오.
기술 FAQ: cxlcloud 방식의 인프라에서 CXL 용량을 재할당한 뒤, 한 테넌트가 다른 테넌트의 메모리를 읽거나 잔존 데이터를 갖지 못한다는 것을 어떻게 검증합니까?
격리를 하나의 사슬로 보고 고리마다 검증하십시오. (1) 바인딩 전에 SPDM으로 각 디바이스를 증명하고 측정된 펌웨어를 고정합니다. (2) FM이 LD 또는 DCD extent를 정확히 한 호스트에만 할당하는지 확인하고, Redfish/FM API로 다시 읽어 바인딩을 검증합니다. (3) 용량을 다시 내놓기 전에 CXL 메모리 디바이스의 Sanitize/Secure Erase 명령이나 검증된 제로화를 반드시 수행하고 완료 상태를 기록합니다. (4) 모든 링크 구간에 IDE를 활성화하고, 컨피덴셜 VM이 대상이면 TSP를 사용합니다. (5) 프리프로덕션에서 네거티브 테스트를 실행합니다. 호스트 간 접근을 시도하고, 예기치 않은 제거를 주입하며, poison이 올바르게 전파되는지 확인하십시오. 어느 단계든 실패하면 해당 extent를 격리하고 여유 풀로 되돌리지 마십시오.