O Linux está acelerando para a próxima geração de servidores. Uma nova série de patches — liderada por Robert Richter (AMD) — introduz suporte de tradução de endereços via ACPI PRM para o ecossistema CXL, mirando habilitar o recurso day-one nos futuros AMD Zen 5. Em termos simples: é o passo que faltava para o kernel entender corretamente como os dispositivos CXL “enxergam” a memória nessas plataformas, garantindo que “falem a mesma língua” do sistema. A série está baseada em cxl/next, o que indica trabalho para a próxima janela de merge (Linux 6.18).
Traduzindo endereços: o desafio do CXL no Zen 5
Imagine que o sistema principal (o “host”) e um dispositivo CXL (por exemplo, um expansor de memória) vivam em “cidades” diferentes e usem CEPs distintos para o mesmo local. No jargão técnico, esses CEPs são endereços físicos: o do dispositivo (HPA, Host Physical Address no contexto do endpoint) e o do sistema (SPA, System Physical Address). Em plataformas AMD Zen 5 com Normalized Addressing, o dispositivo usa um “CEP” próprio — o que significa que, se o kernel tentar entregar um pacote usando o CEP errado, o dado não chega.
O novo código age como um serviço de correio: ele traduz o CEP do dispositivo (HPA) para o CEP do sistema (SPA) antes de roteá-lo. Essa tradução é feita por um mecanismo de firmware padronizado, o ACPI PRM (Platform Runtime Mechanism), que fornece handlers para converter endereços de forma segura e eficiente — no caso, um handler que transforma DPA → SPA (endereço físico do dispositivo para endereço físico do sistema). A documentação pública da AMD descreve esses handlers de tradução no ACPI v6.5 Porting Guide (Pub. #58088).
O que muda no kernel (sem mergulhar em 11 patches)
Em vez de listar cada patch, vale destacar a ideia central: a série introduz um callback genérico de tradução de endereços nos ports CXL. Esse callback permite que o kernel pegue o intervalo de HPA programado no endpoint e o converta passo a passo até o root port, onde o intervalo passa a valer como SPA. Com isso, o kernel consegue:
- Calcular corretamente as regiões CXL (tamanho, interleaving, posição) mesmo quando o endpoint vive em um espaço de endereçamento diferente do sistema;
- Bloquear reconfigurações manuais de decoders quando a tradução é necessária (evita estados incoerentes);
- Isolar a lógica específica de plataforma (no caso do Zen 5, via ACPI PRM) em um caminho claro, mantendo o restante do driver CXL limpo e reaproveitável para outros cenários.
Em versões anteriores do trabalho, essa habilitação chegou a aparecer como uma pilha maior de mudanças; agora, a revisão consolidada foca em reduzir o diff e remover dependências específicas, preparando inclusive documentação das “Convenções de CXL no Linux”. Em paralelo, a implementação AMD usa o PRM para expor a tradução DPA→SPA ao kernel, sendo o ponto que “ativa” o suporte no Zen 5.
Leitura complementar: versão inicial da série com a proposta de tradução e habilitação no Zen 5 (capa v1 no Patchew) e nota técnica da AMD com o PRM e a tradução de endereços (ACPI v6.5 Porting Guide – Pub. #58088, PDF).
Um esforço colaborativo da indústria
O fato de a série vir na v3 já diz muito: houve rodadas de revisões, com comentários extensivos da comunidade linux-cxl e de nomes conhecidos da infraestrutura de memória — incluindo Dan Williams e Dave Jiang (Intel). Esse empurra-empurra saudável resultou em uma solução mais genérica (menos ifdeffery de plataforma), com menos patches e melhor integração com a árvore de cxl/next. Em discussões anteriores, testers como Gregory Price relataram validações em plataformas com PRM ativo e tradução habilitada, reforçando o caminho escolhido. Em suma: concorrentes no mercado, mas parceiros no kernel.
Por que isso importa para quem opera data centers
Para administradores e SREs que planejam adotar CXL em ambientes AMD Zen 5, a mensagem é clara: o Linux está preparando a casa para suporte robusto desde o dia 1. A tradução de endereços é o “detalhe invisível” que destrava o resto: descoberta automática de regiões CXL, cálculo correto de interleaving e mapeamentos coerentes entre HPA, SPA e DPA — sem gambiarras.
Outro ganho é o caminho de manutenção: ao concentrar a especificidade em um callback e reutilizar o PRM como contrato de firmware, o kernel evita forks de código por fabricante e abre espaço para outras arquiteturas adotarem modelos equivalentes. E, como a série está em cxl/next, a expectativa natural é que esse trabalho entre na próxima janela de merge (Linux 6.18), alinhando o calendário do kernel ao dos servidores Zen 5. Isso é “Linux AMD CXL” saindo do papel para a prática.
