Se CXL já é o novo “barramento de tudo” nos data centers, faltava ao Linux um alicerce igualmente sólido para quando as coisas dão errado. Uma série massiva de patches (v11, com 23 mudanças) liderada por Terry Bowman chega justamente para isso: habilitar tratamento e registro robustos de erros de protocolo CXL — não só nos endpoints (dispositivos de memória), mas também nas CXL Ports ao longo da hierarquia PCIe. Em termos práticos, administradores ganham visibilidade, telemetria e rotas de recuperação muito mais previsíveis quando um link CXL pisca, quando há paridade no cache ou quando a camada de transação tropeça.
Por que isso importa
CXL virou pilar para desagregação e pooling de memória: você conecta grandes bancos de DRAM ou memória persistente a CPUs/GPUs e move dados num ritmo que faria inveja a velhos NUMA. Só que, sem um framework de RAS (Reliability, Availability and Serviceability) confiável, qualquer “espirro” num switch ou porta derruba a casa: quedas de performance enigmáticas, panes difíceis de diagnosticar, até corrupção silenciosa. O que essa série entrega é um mapa claro de quem errou, onde e com qual gravidade, e uma resposta padronizada no kernel — do log amigável ao reset controlado, passando por panic deliberado nos cenários fatais onde continuar seria pior.
O que muda no kernel
Em vez de espalhar ifdefs e gambiarras pelo AER (Advanced Error Reporting) do PCIe, o código CXL ganha endereço próprio e uma cara moderna:
- Novo guarda-chuva de configuração: sai o antigo
CONFIG_PCIEAER_CXL; entraCONFIG_CXL_RAS(e, para topologias específicas,CONFIG_CXL_RCH_RAS). Isso desacopla a lógica CXL do AER genérico e deixa claro quando o suporte RAS de CXL está ativo. - Organização por responsabilidades: a parte CXL migra para
drivers/cxl/core/ras.c; no lado PCIe, o que é específico de CXL vai paradrivers/pci/pcie/cxl_aer.ce…/rch_aer.c(Restricted CXL Host), mantendo o AER “core” mais limpo. - Detecção correta de “quem é CXL”: a função
pcie_is_cxl()verifica os DVSECs (os registros estendidos do padrão CXL) e cacheia nopci_devse o dispositivo fala CXL.mem e/ou CXL.cache. Por quê isso importa? Porque o AER agora sabe diferenciar se um evento é um “PCIe Bus Error” tradicional ou um “CXL Bus Error”, e loga com esse rótulo — adivinhe quem agradece na hora de filtrar alertas… - Mão na massa no RAS CXL: o kernel mapeia os registradores RAS de portas e endpoints CXL, lê status de erros corrigíveis e não corrigíveis, despeja o Header Log do CXL (a pista forense do primeiro erro) e limpa os bits para o próximo evento. Tudo com tracepoints unificados (memdev, host, serial), prontos para suas ferramentas favoritas.
- Encaminhamento inteligente de erros: quando o AER capta algo que, na prática, é de responsabilidade do CXL (ex.: um “internal error” em RCEC para RCH), ele encaminha ao driver CXL usando uma fila (kfifo) e workqueue dedicadas — nada de bloquear a interrupção despejando logs.
- Portas com silêncio quando necessário: a série também ativa/desativa as interrupções de protocolo CXL durante o “nascimento” e a desmontagem de uma CXL Port, evitando travamentos e estados zumbis.
- Nomes e APIs mais claras: o código elimina helpers redundantes, limpa condicionais, move DVSECs do CXL para o cabeçalho UAPI de
pci_regs.h(com nomes padronizados), e exporta utilitários comopci_ers_merge_result()para consolidar resultados de recuperação.
Como isso se traduz na operação
Pense no fluxo assim: um link dá erro → AER intercepta → checa se é CXL (via pcie_is_cxl()) → registra como CXL Bus Error com severidade (corrigível, não fatal, fatal), captura o header quando há múltiplos bits acesos (o “primeiro erro” real) e despacha ao handler CXL.
Nos endpoints, o cxl_error_detected() decide o caminho: se o canal está “congelado”, o driver se desliga e pede reset; em fatalidades de cache/memória, o kernel entra em panic — medida dura, mas correta para impedir corrupção.
Em RCH (Restricted CXL Host), a história tem nuances: o RCEC sinaliza “internal error” quando o problema nasceu em uma Downstream Port do CXL. A nova lógica percorre o conjunto de funções por trás do RCEC e acorda apenas quem é CXL.mem e está sob AER nativo — nada de acordar meio mundo à toa.
O que os testes mostram
O time validou com QEMU montando uma sub-topologia completa (Root Port → Upstream Switch → Downstream Switch → Endpoint) e injetando erros corrigíveis e fatais em cada ponto. O que aparece? Logs com “CXL Bus Error”, severidade bem classificada, header log extraído quando faz sentido e caminhos de recuperação coerentes (inclusive os casos que terminam em panic, por segurança).
Impacto para quem opera e desenvolve
- Observabilidade de verdade: logs e tracepoints que distinguem PCIe vs CXL, porta vs endpoint, com serial para casar com inventário.
- Menos falsos positivos: correções só limpam o que importa; não-fatal não vira novela; fatal não disfarça.
- Automação mais simples: com severidade e origem confiáveis, dá para orquestrar resets e evacuar workloads sem caça ao culpado.
- Base para o que vem: à medida que Linux CXL support amplia (coerência, pooling entre nós, memória de próxima geração), um RAS consistente vira pré-requisito, não “nice to have”.
Em que pé está? É a v11 de uma série grande — madura, com testes e assinaturas de revisão — e o tipo de mudança que costuma entrar por partes. Mesmo assim, o recado é claro: o Linux está profissionalizando o tratamento de erros CXL no ritmo que o data center composto exige.
