O Linux 7.3 corrige a falha em SSDs Samsung 990 PRO e EVO Plus que quebrava o passthrough VFIO para máquinas virtuais. Entenda a correção e o impacto
O Problema: A Promessa Não Cumprida do Immediate Readiness
Tudo começou com um recurso introduzido no padrão PCIe 4.0: o Immediate Readiness (Prontidão Imediata).
Este bit permite que um dispositivo sinalize ao sistema operacional que está pronto para responder a comandos de configuração imediatamente após um reset, sem a necessidade de uma espera padrão.
Em teoria, isso acelera a interação do sistema com o hardware.
No entanto, a realidade para os proprietários dos SSDs Samsung 990 PRO (ID PCI 144d:a80c) e 990 EVO Plus (ID PCI 144d:a80d) era diferente. Pelo menos algumas versões de firmware desses drives estavam anunciando o suporte ao Immediate Readiness sem realmente cumpri-lo.
Na prática, após um Function Level Reset (FLR) — um tipo de reset de função PCIe —, o drive levava até 7 milissegundos para responder, retornando um valor inválido (~0) em vez de estar pronto.
Produto Recomendado
Eu ganho uma comissão quando você faz uma compra.
A Regressão no Kernel e o Impacto no VFIO
O problema existia, mas estava latente. A situação se agravou com a inclusão do commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs") no kernel Linux 7.2.
Historicamente, o kernel do Linux tentava restaurar os BARs (Base Address Registers) de um dispositivo até dez vezes após um reset, como uma rede de segurança. Acreditava-se que essa rede de segurança era redundante, pois o kernel agora esperava até 60 segundos para que o dispositivo saísse do estado de reset.
Contudo, essa lógica tinha uma exceção: dispositivos que anunciavam o Immediate Readiness pulavam a espera.
Com a remoção das tentativas de restauração, a configuração pós-FLR era simplesmente perdida para os SSDs Samsung, pois o kernel não esperava o tempo necessário para que eles estivessem realmente prontos.
O impacto foi sentido de forma mais crítica por usuários de virtualização. O driver vfio-pci realiza um FLR sempre que uma máquina virtual é iniciada.
Com a falha, o passthrough VFIO desses SSDs para VMs quebrava, fazendo com que o drive deixasse de funcionar dentro do ambiente virtualizado.
Um exemplo claro foi relatado em um fórum do Arch Linux: um usuário com uma máquina Ryzen 9 9900X e uma GPU RTX 4070 Super passava um SSD 990 EVO Plus para uma VM Windows 11, e o drive parou de funcionar após a atualização para o kernel 7.2.2.
A Solução: Um "Quirk" de Confiança Zero
A solução, desenvolvida pelo desenvolvedor Alexander Gruhlke, foi elegante e direta. Em vez de tentar adivinhar qual firmware era problemático, a abordagem foi parar de confiar na declaração do dispositivo.
O patch, que consiste em apenas doze linhas no arquivo de quirks do PCI, faz o seguinte:
1. Identifica os SSDs Samsung 990 PRO e 990 EVO Plus que afirmam ter Immediate Readiness.
2. Limpa a flag de Immediate Readiness para esses dispositivos específicos.
3. Registra um aviso no log do sistema (KERN_INFO).
4. Força o kernel a esperar o tempo necessário após o FLR, como faria com qualquer outro dispositivo que não anuncia o recurso.
A correção foi inicialmente proposta para o 990 PRO e, posteriormente, o mantenedor do PCI, Bjorn Helgaas, incorporou o 990 EVO Plus ao mesmo patch após confirmar que ele apresentava o mesmo comportamento com o firmware 2B2QKXG7.
É importante notar que o firmware mais recente do 990 PRO, o 8B2QJXD7, parece responder corretamente após o FLR, mas versões mais antigas, como a 1B2QJXD7, não o fazem.
Como a versão do firmware não é visível para o kernel no momento do quirk, a abordagem de bloquear o recurso para todos os dispositivos com os IDs PCI correspondentes é a mais segura e garante a compatibilidade.
❓ Questionário (3 Perguntas sobre o Resumo)
1. Qual era o problema causado pelo recurso Immediate Readiness nos SSDs Samsung 990 PRO e 990 EVO Plus?
Resposta: Pelo menos algumas versões de firmware desses SSDs anunciavam o suporte ao Immediate Readiness, mas não o cumpriam, levando até 7 milissegundos para responder após um Function Level Reset (FLR). Isso quebrava o passthrough VFIO dos drives para máquinas virtuais.
2. Qual foi a causa da regressão no kernel Linux 7.2 que agravou o problema?
Resposta: A regressão foi causada pelo commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs"), que removeu as tentativas de restauração dos BARs após um reset. Como o kernel pulava a espera para dispositivos que anunciavam o Immediate Readiness, a configuração dos SSDs Samsung era perdida, pois eles não estavam realmente prontos.
3. Como a correção implementada no kernel Linux 7.3 resolve o problema?
Resposta: A correção adiciona um "quirk" que identifica os SSDs Samsung 990 PRO e 990 EVO Plus com IDs PCI específicos e limpa a flag de Immediate Readiness para esses dispositivos. Com isso, o kernel passa a esperar o tempo necessário após o FLR, como faria com qualquer outro dispositivo, garantindo que a configuração seja restaurada corretamente e o passthrough VFIO volte a funcionar.
Conclusão
A correção integrada ao Linux 7.3 resolve um problema real e crítico para quem usa os SSDs Samsung 990 PRO e 990 EVO Plus com passthrough VFIO.
Ao deixar de confiar cegamente no anúncio de Immediate Readiness desses drives, o kernel volta a esperar o tempo necessário após o FLR e restaura a configuração de forma segura. A mudança é pequena no código, mas tem grande impacto na estabilidade da virtualização.
Se você depende desses SSDs em máquinas virtuais, atualize para o kernel 7.3 assim que possível. Para acompanhar as versões oficiais, consulte o site do kernel Linux.
A recomendação é simples: mantenha o sistema atualizado e teste o passthrough VFIO após a atualização para confirmar que o drive volta a funcionar normalmente dentro da VM.
Nenhum comentário:
Postar um comentário