When Tenant Boundaries Fail to Contain CXL Memory Loss
A CXL memory link can disappear without violating tenant access permissions and still interrupt every workload whose live state depends on it. In a shared cloud memory pool, address isolation does not establish availability isolation. The root cause begins where the architecture treats those boundaries as equivalent.
The trigger exposes a shared dependency
Consider a failure scenario in which a downstream memory link drops while separate bare-metal tenants hold active allocations behind it. The trigger is the link loss, while the visible symptom is interrupted memory access across tenants that cannot read each other’s allocations. The underlying assumption is that partitioning capacity also partitions the consequences of losing its backing hardware. Reconstructing the incident requires correlating host address mappings, interleave configuration and switch topology with the link event, because an allocation ledger records ownership without necessarily exposing shared dependencies. If those mappings converge on the failed path, simultaneous tenant disruption follows from placement, without requiring an isolation breach or an operator mistake.
Containment cannot reconstruct memory
Keeping unaffected memory accessible preserves useful operation, but it does not recover the live contents that the failed path has made unreachable.
The boundary must survive a real access
The CXL standards family provides error signaling and containment mechanisms, and its error isolation specification explicitly addresses continued platform operation after errors including unexpected link loss. That capability is conditional on the implemented hardware and host recovery path, rather than a guarantee that an application touching the affected range can continue. For a deployment using a 4 KiB base page, interleaving below that boundary can make an operating system page depend on multiple memory targets, so placement must be evaluated at the unit software can actually retire or reconstruct. Bare-metal provisioning should therefore keep recovery services and indispensable host state outside the dependency being isolated, while workload placement must account for shared switches, controllers and power. This sacrifices some pooling freedom and bandwidth aggregation, but prevents a capacity optimization from silently expanding the set of tenants that must recover together.
Prove recovery before promising continuity
Apply this decision rule: admit a workload to pooled memory only when losing its backing failure domain leaves either sufficient valid state to continue or an independently reachable recovery source. Spare capacity alone does not satisfy that rule, because remapping an address to an empty device cannot recreate the data formerly stored there. Replicated application state must preserve the required update ordering and place its recovery copy outside the same dependency, while checkpoint recovery must explicitly accept the work lost since the checkpoint. Validate the design by interrupting the backing link during active access and checking that unaffected tenants progress, affected workloads follow the intended recovery path, and reassignment cannot expose the previous tenant’s contents. The remaining choice is economic and architectural: pay for independent state and reserved recovery capacity, or offer a service whose contract permits restarting the affected workload.